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FOREWORD 


A Cost and Utility Analysis of NIM/CAMAC Standards and Equipment for 
Shuttle Payload Data Acquisition and Control Systems was performed by the 
Defense and Space Systems Group of TRW, Inc. under Contract NAS9-14693 for 
the Lyndon B. Johnson Space Center of the National Aeronautics and Space 
Administration. The work v/as managed by Dr. Richard J. Kurz (Telephone 
(213) 535-2936) of the Instrument' Systems Department, TRW Defense and 
Space Systems Group. The study was administered under the technical 
direction of Dr. Richard D. Eandi (Telephone (713) 483-5176) of the Space 
Physics Branch, Johnson Space Center. 

The results of the study are presented in three volumes: 

VOLUME I. SUMMARY 

Overall summary of the analyses and conclusions 

VOLUME II. TASKS 1 AND 2 

Identification and. selection of representative payloads for analysis 
and functional analysis of the selected paylaods for NIM/CAMAC equipment 
applicability and commonality. 

VOLUME III. TASKS 3 AND 4 

Analysis of the modifications to NIM/CAMAC equipment required for 
compatibility with the Spacelab environment and their estimated cost, 
development of a management plan for the utilization of NIM/CAMAC equipment 
and programmatic cost estimates, and assessment of the implementation and 
impact of CAMAC software. 
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1. MODIFICATION ANALYSIS OF NIM/CAMAC EQUIPMENT (TASK 3) 


1.1 INTRODUCTION 

Our objectives in this task were: 1) to determine what modifications 
NIM/CAMAC equipment in its current form, i.e., designed for ground-based 
laboratory use, would be required to permit its use in the Spacelab environ 
ment, and 2) to estimate the cost of these modifications and identify the 
most cost-effective approach to implementing them. Our effort was corres- 
pondingly divided into two tasks, the first of which was performed in two 
phase?. 

Task 3A (First Phase) - Assemble and Evaluate NIM/CAMAC and Spacelab 

Information 

• Compile available NIM/CAMAC data and specifications. 

• Review various Spacelab specifications and update the Rockwell 
Spacelab/Experiment Equipment Interface Requirements (SEEIR) to 
recommend design criteria. 

t Assess incompatibilities between existing NIM/CAMAC equipment 
and current Spacelab requirements. 

t Determine needs for additional data on NIM/CAMAC equipment. 

• Prepare preliminary recommendations to the Shuttle Environmental 
Compatibility Test (SECT) program. 

Task 3A (Second Phase ) - Analyze NIM/CAMAC Suitability for Spacelab 

Environments 

f Analyze NIM/CAMAC equipment with respect to dynamic, thermal, 
electromagnetic compatibility; and parts, materials, and pro- 
cesses characteristics. 

0 Prepare recommendations for SECT based on analytical results. 

0 Review SECT results. 

Task 3B - Analyze Required Modifications and Determine Costs 

0 Determine NIM/CAMAC modifications required to meet Spacelab 
environments. 

0 Estimate modification costs. 

0 Identify cost-effective modification source. 

Due to its standardized nature, NIM/CAMAC equipment has a considerable 
amount of inherent mechanical commonality, irrespective of manufacturer or 
function. This fact has allowed us to perform much of the modification 
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analysis in parallel with the functional analysis carried out in Task 2 of 
the study. In addition, the greater applicability of CAMAC equipment found 
in the course of performing Task 2 led us to place a greater emphasis on 
CAMAC equipment in Task 3. 

Because of delays in the SECT program, which was intended to be carried 
out in parallel by JSC, test data were not available during the contract 
period of performance for review as originally planned in the second phase 
of Task 3A. As a consequence, we undertook a more extensive dynamic and 
structural analysis than had originally been intended. Again, the standard- 
ized nature of NIM/CAMAC equipment made it meaningful to perform detailed 
analysis using a generalized structural computer model of the equipment. 

Our original planning for Task 3B included an analysis of the trade-off 
between the degree and costs of equipment modification and changes to the 
cost-driving Spacelab environmental requirements. As we will see from the 
results of Task 3 and the programmatic cost estimation in Task 4A (see 
Section 2), the costs involved in even the most extensive equipment modifi- 
cations that we will consider are relatively small on the scale of the costs 
that would be involved in making significant changes to the important Space- 
lab environments such as random vibration. We believe, therefore, that it 
is clearly more cost effective to modify NIM/CAMAC equipment to be compat- 
ible with the Spacelab environment rather than the converse. 

The basic reference documents used in performing Task 3 are listed in 
Table 1-1. A new version, May 1976, of the Spacelab Payload Accommodation 
Handbook has recently become available, but the differences between the 1975 
and 1976 versions do not significantly affect the results of this study. 
Although they are not listed in Table 1-1, numerous catalogs and specifica- 
tion sheets from NIM and CAMAC equipment manufacturers were also used in 
addition to the publications listed in Table 1-1 of Volume II. 

1.2 ANALYSIS OF NIM/CAMAC AND SPACELAB SPECIFICATIONS 

(TASK 3A - FIRST PHASE) 

1.2.1 NIM/CAMAC Equipment Characteristics and Specifications 

The overall physical characteristics of NIM and CAMAC equipment are con 
trolled by the standards. Specification drawings for both systems are avail 
able. Drawings for CAMAC are contained in ERDA Report TID-25875 and a 
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Table 1-1. References Used in the NIM/CAMAC Equipment 
Modification Analysis 

Spacelab Payload Accommodations Handbook, ESRO, May 1975. 

Space Shuttle System Payload Accommodation, JSC 07700, Volume XIV, Revision D, 
November 1975. 

Analysis of Commercial Equipment and Instrumentation for Spacelab Payloads, 
Rockwell SD74-SA-0047 , September 1974, 

Feasibility Study of Common Electronic Equipment for Shuttle Sortie Experi- 
ment Payloads, Bendix BSR 4142, June 1974. 

Natural and Induced Environments, ERNO SR-ER-0008, February 1976. 

Random Vibration Flight Environments at Spacelab Equipment Locations, ERNO 
TN-ER-40-020-75, October 1975, 

Engineering Development Test Procedures for NIM/CAMAC Instrumentation, 

NASA/ JSC, March 1976. 

Selected publications regarding NIM and CAMAC, see Table 1-1, Volume II of 
this report. 

drawing set (CAPE-1189) for NIM is available from the Clearinghouse for Fed- 
eral Scientific and Technical Information. The general physical character- 
istics of the CAMAC system can be seen in Figures 1-1 through 1-4, Although 
the construction details vary between models and manufacturers, the modules 
shown in Figure l-S and 1-4, with side covers removed, are reasonably repre- 
sentative of typical CAMAC and NIM, respectively. 

The NIM and CAMAC standards do not specify environmental requirements 
other than a general statement that the equipment is intended for use in 
environments typically associated with laboratory instrumentation (e.g., 
the ambient temperature range of roughly 0 °C to 50 °C) . Very little pub- 
lished data on environmental chara;;teristics of NIM and CAMAC equipment 
exist. The CERN laboratory of the European Organization for Nuclear Research 
has generated a series of internal test reports on NIM and CAMAC modules 
that include some thermal test results. Typically, individual modules are 
checked for proper functional performance over the temperature range of 
0 to 60 °C. In several cases, vibration tests were also performed but the 
test conditions are not defined in the reports. 
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Figure 1-1. Front View of CAMAC Modules Loaded in a CAMAC Crate 



Figure 1-2. Rear View of CAMAC Crate and Modules with 
Power Supply Removed 
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In lieu of any published data or specifications, we contacted a number 
of equipment manufacturers as well as equipment users. In particular, a 
trip was made to Lawrence Berkeley Laboratory of the University of California 
where a large amount of NIM and CAMAC equipment is used and some special 
purpose NIM and CAMAC equipment is designed and fabricated for internal use. 
It was possible to both inspect a wide spectrum of NIM and CAMAC equipment 
from a number of manufacturers and to discuss operating experience with 
equipment users. In addition, several engineers at LBL are members of the 
NIM Committee and have been involved in the standardization activity for 
both NIM and CAMAC since its inception. 

The results of this information gathering that are relevant to the 
question of NIM/CAMAC usage in Spacelab payloads are summarized in the fol- 
lowing sections. 

1 . 2 . 1 . 1 Structural and Dynamic Properites 

Although the structural characteristics of NIM and CAMAC equipment are 
reasonably well defined by the standards, and the manufacturers uniformly con- 
form to the standards, essentially no formal analysis or testing of the 
structural behavior under dynamic environments have been conducted. 

1.2. 1.2 Thermal Characteristics 

Both NIM and CAMAC equipment depend on convective air flow for cooling. 
In the case of NIM equipment, where the maximum power dissipation in a bin 
is typically 72 watts, natural convection in a one-g environment is adequate 
for reliable operation at ambient temperatures up to 50 °C. Fans are neces- 
sary to provide increased air flow when either the power dissipation in an 
individual bin is increased or when a number of bins of equipment are stacked 
in one rack enclosure. 

For CAMAC equipment, where the maximum power dissipation in a crate is 
typically 300 watts, forced-air cooling must be used at'all times. The CAMAC 
standards recommend at least 48 cfm of air-flow per crate and a forced-air 
system is routinely included as part of the powered crate (see Figures 1-1 
and 1-2). Fans, located in a plenum below the modules, draw ambient air 
through a front panel filter and distribute the air up through the modules. 
The actual air flow provided in commercial crates is not specified. The 
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manufacturers use whatever fan capacity is required to obtain reliable opera- 
tion in the field. For example, one of the most commonly used crates, manu- 
factured by Standard Engineering Corporation, uses three fans that have a 
total free-air capacity of 350 cfm. 

1 . 2 . 1 . 3 Parts, Materials, and Processes Characteristics 

The basic modules consist of a printed-wiring circuit board attached 
to a metal frame (see Figures 1-3 and 1-4). The electronic parts used by 
NIM and CAMAC manufacturers are almost universally industrial grade, 0 °C 
to 70 °C operating range. Next to the required functional characteristics, 
cost is usually the most important factor in parts selection. The frequently 
used parts are of the type that are generally available in full military 
temperature range (-55 °C to 125 °C) and high-reliability versions. 

The types of connectors that can be used on NIM and CAMAC equipment are 
defined by the standards. 50-ohm BNC type or NIM-CAMAC-Type 50-CM coaxial 
connectors are specified. The CAMAC dataway connector is an 86-contact card 
edge connector specified in the CAMAC standards. The standard NIM power 
connector is a special multicontact, mating pin-socket connector that includes 
guide pins and sockets. The CAMAC standards recommend two types of multi- 
contact mating rectangular connectors for auxiliary use: 52-contact 2D sub- 

i ... 

miniature, and 88- or^ 152-contact WSS subminiature. 

The types of materials used in NIM and CAMAC equipment are quite common. 
Structural elements are aluminum, printed circuit boards are epoxy fiberglass 
and wiring is multistrand. Teflon or PVC insulated. Subminiature RG-type 
coaxial cable is frequently used for noise sensitive signal runs inside the 
modules. Miscellaneous uncontrolled plastics are present in the form of 
knobs and component cases. 

Although the standards do not control manufacturing workmanship and 
methods or specify any quality assurance requirements , the commercial modules 
do conform uniformly to good standard commercial practice. The main process 
of concern in module fabrication is soldering, and the general quality of 
workmanship observed was good. With respect to wiring, typically very little 
stress relief or mechanical support to wiring is used. 

1.2.2 Spacelab Environmental Requirements 

For the analysis of NIM/CAMAC equipment, we were primarily concerned with 

t 

the environmental requirements on equipment mounted in the racks of the 
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Spacelab module since this is the most likely location for NIM/CAMAC equip- 
ment. Other possible locations for the equipment include rack-mounted on 
the rear deck of the Orbiter cabin, mounted in a Spacelab Igloo, or pallet- 
mounted in the payload bay. The Orbiter cabin environments are not signi- 
ficantly different from the Spacelab module environments. The Igloos are 
currently intended to be used only for Spacelab subsystem equipment. If 
Igloos are available for experiment equipment, there is still at least one 
significant difference in the environment from the standpoint of NIM/CAMAC 
equipment. Although the Igloo is pressurized and temperature controlled, 
no forced-air convective cooling capability is planned. It is possible to 
consider modification of NIM/CAMAC equipment to allow operation without 
convective cooling and the NASA/GSFC NIM/CAMAC activity is, in fact, doing 
so. Although we will discuss this possibility briefly in our assessment of 
NIM/CAMAC compatibility with the Shuttle environments, our primary attention 
will be directed to the Spacelab module environment. 

Assuming the equipment is located in the Spacelab module, the environ- 
ments that are of principal interest are the dynamic and thermal environments. 
At the time of our activity to establish environmental requirements for 
Spacelab rack-mounted equipment, several different environmental specifica- 
tions were available as design criteria. The appropriate specifications 
contained in the first four references listed in Table T-1 are compared in 
Table 1-2 and the specification recommended for use in this analysis is 
defined. 

The recommended specification was an extrapolation of our own space- 
craft experience, a comparison of acoustic levels, and an examination of 
the shielding provided by the Shuttle and Spacelab. NASA/JSC, for their 
SECT program, increased the proposed random vibration environment to an over- 
all test level of 12 grms , and we consequently performed our dynamic analy- 
ses using this level. The more recent references listed in Table 1-1 indi- 
cate that equipment will be exposed to an even more benign environment 
than that recommended by TRW in Table 1-2. The random vibration overall 
level is down to 3.3 grms in SR-ER-0008 and the May 1976 Spacelab Payload 
Accommodations Handbook. We expect that when complete Shuttle tests have 
been conducted, the more benign environment will prove to be correct and 
our calculations and the JSC tests will generally have been conservative. 
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Table 1-2. Comparison of Shuttle Payload Environments 



SPACELAB 

ROCKWELL 

BENDIX 

VOL XIV 

TRW RECOMMENDATION 

Sinusoidal 

Vibration 

5-35 Hz 
0.25 g 

x-axis 

3-8.5 Hz 
(0.8" DA) 

8.5-35 Hz 
(3.0 g) 

35-50 Hz 
(1.0 g) 

Undefined 

5-35 Hz 
(0.25 g) 

Nonrandom vibration would 
control in frequency- 
sensitive region (>50 Hz) 

A 1.0-g Sine Sweep from 
10-2000 Hz at l.O-Octave/ 
Min is recommended for 
determination of dynamic 
characteristics 



y- and z-axis 






3-7 Hz 
(0.8" DA) 






7-35 Hz 
(2.0 g) 




Random 

Vibration 

20-200 Hz 
(+8 dB/oct) 

20-60 Hz 
(+6 dB/oct) 

Shape Undefined 

50-110 Hz 
(+6 dB/oct) 

20-200 Hz 
(+8 dB/oct) 

200-700 Hz 
(0.1 g2/Hz) 

60-500 Hz 
(0.14 g2/Hz) 

Probably Flat 
from 70-130 Hz 

110-700 Hz 
(0.9 g2/Hz) 

200-700 Hz 
(0.1 gZ/Hz) 


700-900 Hz 
(-18 dB/oct) 

500-2000 Hz 
(-9 dB/oct) 


700-1200 Hz 
(-9 dB/oct) 

700-900 Hz 
(-18 dB/oct) 


900-2000 Hz 
(0.02 g2/Hz 




900-2000 Hz 
(0.02 gZ/Hz) 


Overall - 
10-g rms 

Overall - 
10.6-g rms 

Overall - 
14-g rms 

Undefined 

Overall - 10-g rms 


Duration 

Undefined 

Duration 

Undefined 

Duration 

Undefined 


Duration - 1 minute 




Table 1-2. Comparison of Shuttle Payload Environments (continued) 


SPACELAB 

ROCKWELL 

BENDIX 

VOL XIV 

TRW RECOMMENDATION 

Acoustics 






Overall 

138 dB 

Undefined 

Undefined 

145 dB 

None - random vibration 

Max Level 

130.5 dB 

131 dB 


135 dB 

is adequate to envelope 

(1/3 Octave) 




effects of acoustics. 

Frequency 
for Max 

200-500 Hz 

300-400 Hz 


200-500 Hz 


Level 






Pyrotechnic 

Undefined 

Undefined 

Undefined 

Undefined 

None - considering the 

Shock 


(Will be less 
than vibration/ 
acceleration) 



location of the equipment, 
shock would be attenuated 
to nondestructive levels. 

Landing 

1.5 g 

Undefined 

Undefined 

1.5 g 

None - covered by vibration. 


260 mill isec 

(Will be less 


260 mill isec 



Rectangular • 

than vibration/ 
acceleration) 


Rectangular 


Crash Shock 






Level 

40 g 

9 g 

8 g 

40 g 

None - covered by vibration 

Duration 

11 mill isec 

Undefined 

Undefined 

11 mill isec 

for internal structure. 

Pulse 

Shape 

Sawtooth 



Sawtooth 

Should only be used for 
analysis of mounting hard- 
ware to ensure no catastro- 
phic failure 


Constant 

4.0 g (-x) 

3.3 g (-x) 

+4 g all axes 

4.4 g (x) 

None - covered by vibration. 

Acceleration 






(Worst Case) 








Table 1-2. Comparison of Shuttle Payload Environments (continued) 


Temperature 
(Air Cooled) 

SPACELAB 

ROCKWELL 

BENDIX 

VOL XIV 

TRW RECOMMENDATION 

Max Inlet 
Temp. 

35 °C 

29 °C 

29 °C 

N/A 

35 °C 

Min Inlet 
Temp . 

Undef i ned 

26 °C 

18 °C 


Not required 

Pressure 

1 .0 Bar 

14.7 psia 

14.7 psia 


14.7 psia 

Flow Rate 

.22 kg/hr/watt Undefined 

Undefined 


.22 kg/hr/watt 



Our recommended general structural and thermal analysis criteria are 
presented in Table 1-3. 

Table 1-3. Structural and Thermal Analysis Criteria 

Structural 

t The random vibration environment will be controlling since 
it will excite resonances causing inertial loads exceeding 
those of sinusoidal vibration, acoustics, pyrotechnic shock, 
and landing shock for most structures. Crash shock should 
be considered for mounting hardware only. 

0 Load factors for analysis will be based upon 3-sigma resonance 
response of a single degree of a system having a transmissi- 
bil ity of ten. 

0 A minimum resonant frequency is to be determined to preclude 
peak circuit board deflections in excess of 0.1 inch, double 
amplitude. 

0 Margins of safety for structural members should be at least 
1.25, based upon yield strength. 

Thermal 

0 Forced-air cooling will be available with a maximum inlet 
temperature of 35 °C and a maximum flow rate of 0.22 kg/hr 
per watt of .power dissipated in the equipment. 

0 Allowable electronic part operating temperatures should not 
exceed 125 °C maximum and 70 °C preferred. 
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1.2.3 Preliminary Assessment of NIM/CAMAC Compatibility with 
Space! ab Environments 

1.2. 3.1 Dynamic Environments 

Based on experience with space electronics, our overall assessment after 
examination of a variety of NIM/CAMAC equipment is that it should be capable 
of surviving the dynamic environments without major structural modification. 
The determination of the detailed modifications or changes needed will require 
analysis and/or well -instrumented vibration testing. 

The modifications that we thought would be required are: 

Attachment of Crates or Bins to Racks - The normal front panel attachments 
of the crate and bins to a rack are inadequate. Front attachments by them- 
selves result in a large cantilevered load at a weak section of the front 
panel. The structure must be modified to a rail mount that is compatible 
with Spacelab rack design. 

Module Attachment to the Crate - Modules must have top and bottom screws in- 
stalled with a controlled torque rather than just one thumb screw as now used 
typically. Also, spring fingers or other retaining devices should be placed 
in the card guides to eliminate guide-to-card rail clearance. 

Module Modifications - The corrective actions listed below should be taken 
to prevent structural failures at the component level. 

t Conformal coating is not used on the circuit boards. Thin conformal 
coating (3 to 5 mils) should be used to provide mechanical support 
for small axial lead parts and to provide some vibration damping. 

0 Epoxy bond parts of five grams or heavier not having other support. 

0 Point-to-point wiring that is not stress relieved at points of 

relative motion (such as from front of module to card) is susceptible 
to fatigue failure. These wires should be routed with slack, and a 
bond or other means of support provided near solder joints. 

0 Some axial lead parts have lead bends quite close to the part body 
that can possible result in vibration failure of the leads. Manufac- 
turing guidelines to preclude lead bending at the part body should 
be imposed. 

0 Some parts, such as disc capacitors, are mounted vertically without 
mechanical support for the part body. These should be laid down 
and bonded or otherwise supported. 

0 CAMAC card edge plug-in connectors are not flight qualified and may 
be a vibration problem. Some structural support such as guide pins 
should be provided. 
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• Printed circuit boards are quite large compared to most flight equip- 
ment. For flight, some cards may require the addition of stiffeners. 

• Integrated circuits in dual in-line packages (Dip's) are used exten- 
sively. Problems have been experienced with DIP'S failing after 
environmental exposure. Manufacturing guidelines on lead forming and 
part installation should be imposed to minimize installation stresses 
at the DIP body. 

• Fasteners are not locked. To preclude loosening during vibration, 
torques should be specified and positive locking mechanisms provided 
such as locking hardware or epoxy bonds. 

1 . 2 . 3 . 2 Thermal Environments 

Our general assessment of the compatibility of NIM/CAMAC equipment with 
the Spacelab thermal environment is that the available forced-air convective 
cooling capacity is marginal. Operation without forced-air cooling will not 
be possible without significant modifications to reduce power consumption and 
improve the conductive heat paths in the equipment. 

To be compatible with the Spacelab module forced-air cooling system for 
rack-mounted equipment, a plenum, which provides connection between a crate 
or bin and the rack air return ducts, will be required. This plenum should 
also be designed to provide uniform air flow over all of the modules mounted 
in the crate or bin. 

Even assuming such an arrangement is provided, the situation is marginal. 
The Spacelab air flow rate of 0.22 kg/hr/watt corresponds to 32 cfm for a 
300-watt crate. This is significantly lower than the 48 cfm recommended in 
the CAMAC standard, which itself may be below the flow rate used in commer- 
cial crates. Analysis and testing are definitely required to determine the 
degree of compatibility. The use of electronic parts capable of operating up 
to 125 °C is probably desirable in any case. 

A very simplified calculation of the heat paths available to conduct 
heat from the electronic parts in a CAMAC module to the crate structure indi- 
cates that the module part temperatures will rise roughly 25 °C above the 
crate structure temperature for each watt of power dissipated in the module. 
Since the average power dissipation in commercial CAMAC modules is close to 
ten watts, conductive cooling is not adequate. Even with military temperature 
range parts, module power dissipations in excess of about four watts will not 
be tolerable without significant mechanical changes to improve the conductive 
heat paths available. 
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1.2. 3. 3 Electromagnetic Compatibility 

Although it is very difficult to judge without actual test data, we 
believe that no significant problems should be encountered with electromag- 
netic compatibility. In general laboratory usage, electromagnetic compati- 
bility problems within NIM/CAMAC systems or between NIM/CAMAC and other 
equipment seldom occur even though the application is frequently sensitive 
to electrical noise. The basic construction of the NIM and CAMAC system pro- 
vides reasonably good (but certainly not complete) shielding of radiated 
emissions. The question of conducted emissions is more problematical. Al- 
though the standards provide for separate high-quality grounds and power 
return lines, etc., commercial NIM/CAMAC equipment usually has only one com- 
mon circuit ground which is also tied to frame ground. The grounding prac- 
tices used in commercial equipment will have to be improved by consistently 
maintaining isolation between circuit and frame grounds in order to preclude 
problems in meeting Spacelab EM compatibility requirements. EMC testing 
should be performed since it is very difficult to perform conclusive analysis 
of the problem. 

1 . 2 . 3 . 4 Parts, Materials, and Processes 

Parts - As was previously discussed in Section 1.2. 3. 2, the thermal environ- 
ment may require the use of parts capable of operating at case temperatures 
up to 125 °C. In other words, military grade parts would have to be used 
in place of industrial grades. From the standpoint of quality assurance 
requirements on electronic parts, the use of high-reliability parts may not 
be necessary. NIM/CAMAC manufacturers frequently burn-in the active parts 
used in commercial units and perform elevated temperature acceptance testing 
of the equipmentto eliniinate defective components. At a minimum, these types 
of screening activities should be universally adopted for NIM/CAMAC equip- 
ment to be used in flight applications. 

The types of coaxial connectors used in NIM/CAMAC equipment are designed 
for easy and convenient connect/disconnect. Users have experienced occasional 
problems with the reliability of the NIM-CAMAC-type 50 CM, Substitution of 
a space-qualified miniature 50-ohm connector type such as the Microdot S-5Q 
series is recommended. The CAMAC dataway card edge connector is an open ques- 
tion. If circuit operation during the launch environments is required, the 
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use of card edge connectors should be eliminated. However^ it appears that 
very little, if any, of the payload NIM/CAMAC equipment needs to be operated 
during launch. Thus, we are not convinced that the card edge connector is not 
acceptable. The question should be settled by testing. 

Materials - NIM/CAMAC equipment should present very few problems since the 
basic materials used are the same as those frequently used in space electronics. 
Some material substitutions will have to be made to assure consistent use of 
flame retardant, low-volatility plastics. For example, only Teflon-insulated 
wire should be used. No particular outgassing problems are expected, especial- 
ly if conformal coating is used as recommended in Section 1.2. 3.1. Naturally, 
a low outgassing conformal coating, such as Soli thane, should be selected. 

The same is true for epoxy bonding materials. 

Processes - In view of the generally good quality of soldering observed in the 
sample of NIM/CAMAC equipment inspected, strict imposition of NASA soldering 
standards is probably not absolutely necessary. However, some criteria should 
be adopted to assure a consistently high level of workmanship. The recommenda- 
tions made in Section 1.2. 3.1 with regard to part lead forming and installa- 
tion practices as well as wiring stress relief are at least as important as 
the soldering techniques. 

1.2.4 Recommendations for the SECT Program 

Initial recommendations for the SECT program were presented to JSC at the 
first briefing and review meeting. These recommendations were based upon the 
activities described up to this point and dealt with dynamic and thermal 
testing as the highest priority tests. 

1 . 2 . 4 . 1 Dynamic Tests 

Sinusoidal vibration testing was recommended to determine frequencies and 
amplifications. The test results are to be used to check the analytical 
results as well as to assist in understanding the system dynamics. Random 
vibration tests were recommended to simulate the expected flight environment 
in order to identify possible failure modes and to determine the peak random 
vibration inertial loads at critical points of the system. No shock, acous- 
tic or constant acceleration tests were recommended because random vibration 
would present more severe loads. 
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Test Levels - 


t Sinusoidal Vibration 


1 g, 10-2000 Hz at 1 oct/mi n - each of 3 axes 


• Random Vibration 



Level 


20-200 +8 dB/octave 

200-700 0.1 g2/Hz 

700-900 -18 dB/octave 

900-2000 0.02 g2/Hz 

Overall Level = 10-g rms 
Duration = 1 minute per axis - 


each of 3 axes 


Test Configuration - 


0 Each crate should have supporting devices to prevent cantil evening 
of the crate as is currently done commercially. 

0 Modules should have screws at top and bottom for torquing into 
crate structure. 

0 Card restraint should be used in crate card guide slots. 

0 Selected boards should be conformally coated so that identical 
boards with and without conformal coat can be compared. 

0 Guide pins should be provided at the CAMAC dataway connector for 
selected modules for comparison to identical modules without guide 
pins. 

0 Structural support frames should be provided for selected boards 
for comparison to identical boards without frames. 


Test Instrumentation - Accelerometers for sinusoidal and random vibration 
should be placed at the locations below in the axis of excitation. The number 
of accelerometers has been limited to eleven per axis since this is typically 
the limit per tape recorder. 


# 1 to 6 - on PC cards center of each’ of 3 types with and without 

modification. 

#7 - on one PC card near connector. 

#8 - on one PC card center edge near front. 

# 9 - crate structure top center rear. 

#10 - crate structure bottom center rear. 

#11 - crate structure top edge rear. 
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Data Reduction - 


t Sinusoidal Test - Filtered transmissibility plots of each of the in- 
line accelerometers for each of the three axes of 
tests. 

0 Random Vibration Tests - Power spectral density plots of each in-line 

accelerometer and very fast speed ('\^20 in/sec) chart 
recorder plots of g vs time for selected accelerom- 
eters having the highest response. Data to be used 
to pick highest g level for inertial loads. 


1 . 2 . 4 . 2 Thermal Tests 

The recommended thermal testing was intended to simulate the Spacelab 
forced-air cooling system. The thermocouple and air flow measurements should 
be made at locations that will provide results that can be used to check and 
update our thermal analyses as well as at locations that are expected to be 
the worst-case points. 

Test Levels - 

• Air Temperature - 35 °C 

• Flow Rate - .22 kg/hr/watt (.11 cfm/watt) and 25%, 50%, 150%, and 

200% of the design rate. 

Test Configuration - 

• In simulated rack with full load of equipment, 

• Closed Air Flow 

Thermocouple Measurements - 

t Inlet and Exit Air 

• Critical Board or Part Temperatures 

Air Flow Measurements: Pressure and Velocity - . 
t At Inlet and Exit 

• At critical locations such as corners to evaluate flow patterns. 
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1.3 ANALYSIS OF NIM/CAMAC SUITABILITY FOR SPACELAB ENVIRONMENTS 
. (TASK 3A - SECOND PHASE) 

1.3.1 Dynamic/Structural Analysis 

The detailed dynamic/structural analysis was undertaken to establish the 
capability of NIM/CAMAC equipment to withstand the Spacelab environments. 
Complete documentation of this analysis is contained in TRW Report 7517.2-854, 
"CAMAC- Dynamic Structural Analysis," April 18, 1976. As discussed in the pre- 
vious section, it is clear that random vibration will be the structural design 
driver, and that a design that can withstand vibration loads will be compatible 
with the shock, acceleration, and acoustics environments. 

Our vibration analysis was directed at obtaining resonant frequencies 
and mode shapes so that the dynamic stresses on structural elements of crate 
and modules could be calculated. In addition, printed circuit board deflec- 
tions and peak accelerations in the system are required to evaluate the prob- 
ability of failures at the component level. 

1.3. 1.1 Random Vibration Environment 

The random vibration power spectral density used as the dynamic environ- 
ment is shown in Figure 1-5 and is identical to the test levels to be used in 
the SECT program. 

1.3. 1.2 Crate Dynamic Model 

A simplified drawing of the crate dynamic model used in the computer 
analysis is shown in Figure 1-6. The dynamic model assumes that the front 
upper and lower card guide castings are held together with three module front 
beams. This simulates the actual condition of multiple module front beams. 

The only physical tie between the modules and crate that affects the 
crate structure is the module front panel which is attached to the crate by 
an upper and lower fastener. The weight of the modules is distributed to the 
crate node points along the card guide locations. The model assumes all 
module guide slots are filled, and that the modules are free to slide in one 
dimension in the guide slots. 
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Figure 1-5. Random Vibration Spectrum Used for Dynamic Analysis and 
and SECT Program 



Figure 1-6. Structural Model of CAMAC Crate Used for Dynamic Analysis 
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The mass applied at each node is assumed to be acting simultaneously 
along all the orthogonal axes, which does not affect uncoupled modes. The 
forces applied for the static stress analysis were also applied simultaneously. 
However, the extreme fiber bending stresses were calculated at cross-section 
positions to reflect load direction independently. 

The dynamic model assumes the modules are held in place by two fasteners. 
For commercial applications, only a single attachment screw is located at the 
bottom of the module front panel. For flight application, it would be neces- 
sary to include a second fixing screw at the top of the front panel similar to 
the NIM modules. The CAMAC standards for the crates make optional a threaded- 
hole pattern on the top crate rail to accept NIM modules. Most manufacturers 
produce their crates with the same 25 threaded-hole pattern on the top crate 
rail as on the bottom rail. The top screw is thus a change to only the CAMAC 
modules. 

The crate dynamic model has 284 joints, 14 constrained joints, 10 beam 
section properties, 283 members, and 32 plate elements. Full fixity boundary 
conditions were assumed at the four corners of the bottom surface and at two 
points on the edges of the two front panel mounting flanges. All other sur- 
faces, including the top, were considered free in all six directions, with 
the exception of plate element nodes which were rotationally fixed in the 
local vertical direction. 

1.3. 1.3 Module Dynamic Model 

The module dynamic model has 15 joints, 13 constrained joints, 3 section 
properties, 12 beam members, and 16 plate elements. The model is depicted in 
Figure 1-7. The module was considered to be pinned in the crate guide rails 
(lateral movement prevented but no rotational constraint). All plate element 
nodes were considered rotationally fixed in the local vertical direction. 

1 . 3 . 1 . 4 Analysis Criteria 

Stress Criteria - Material properties will be minimum as specified in MIL- 
HDBK-5. A factor of safety of 1.25 with respect to the material yield is 
desired for stresses on structural members ; plastic yielding will not be 
allowed. 


21 




Figure 1-7. Structural .Model of CAMAC Module Used for 
Dynamic Analysis 

Stiffness Considerations - Frequently, allowable deflections rather than stress 
will control the design of electronic equipment structure. This is particu- 
larly true for printed circuit boards, connector mounts, and, in general, 
wherever wiring interconnections are of prime consideration. Maximum printed 
circuit board deflections should be below 0.1 inch, double amplitude to avoid 
problems. 

Design Load Factors - The design load factor is an equivalent static accelera- 
tion by which the mass of a resonating structural member is multiplied to 
obtain an equivalent static load for purposes of calculating stress. 

The design load factors are determined from the peak Rayleigh three-sigma 
acceleration, Gp, which is given as a function of frequency by: 

1/2 

Gp = 3(| Q f U) , 

where Q is the assumed transmissibility , f is the frequency, and W is 
the random vibration power spectral density at frequency, f. The peak accel- 
eration calculated from the random vibration spectrum shown in Figure 1-5 
with an assumed transmissibility of ten is plotted in Figure 1-8. The assumed 
transmissibility of ten is toward the lower end of the values expected for 
this type of hardware. A maximum expected value would be twenty. 
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Figure 1-8. Three-Sigma Peak Acceleration Spectrum Used 
for Dynamic Analysis 

The design load factor at a particular resonant frequency, f^, of a 
structural member is the value of the peak acceleration at f^^ given in 
Figure 1-8 after multiplication by a correction factor ranging from 0,5 to 
1.0 to take into account the particular structural configuration. 

1.3. 1.5 Dynamic Analysis Results and Conclusions 

Natural Frequencies - The calculated natural frequencies of the crate struc- 
ture and the module printed circuit boards are listed in Table 1-4. The funda- 
mental and second mode frequencies are relatively low, which will result in 
significant motions. Cable harnesses and wiring will, therefore, need to be 
supported along their lengths to avoid overstressing at cable terminations. 


23 




Table 1-4. Calculated Natural Frequencies of the 
CAMAC Crate/Module System 


Crate Natural Frequencies 


Mode Frequency (Hz) 


1 

2 

3 

4 

5 

6 


53 

92 

125 

128 

130 

139 


Module Printed Circuit Board 
Natural Frequencies 

Mode Frequency (Hz) 

1 53 

2 101 

3 220 

4 251 


Crate Dynamic Stresses - Basic structural elements are stressed well below 
nominal yield stresses. The maximum stress found was 4806 psi which gives a 
margin of safety of 1.9, based upon a yield value of 14,000 psi. The s’cress 
levels are sufficiently low that fatigue of the basic structure will not be 
a consideration. However, all bolts and screws will need to be properly 
torqued and locked. 

Module Dynamic Stresses and Deflection ~ The maximum dynamic stress found was 
600 psi, which is well below the levels allowed in standard aerospace practice 
The maximum printed circuit board deflection was 0.044 inch, double amplitude. 
Although significant, this value is not as large as one would expect intui- 
tively. There is adequate clearance to preclude collision between adjacent 
boards. However, the deflections are sufficiently large to require attention 
to wire routing and attachment to the board. Stress relief and spot bonding 
will be required. Flexing of part leads due to board curvature is normally 
acceptable for board deflections up to 0.07 inch, double amplitude at a mini- 
mum. Stiffening or additional support to the boards should, therefore, not 
be required to preclude part lead failures. 

Peak Accelerations - The peak accelerations shown in Figure 1-8 are, in gen- 
eral , 25 to 35 percent of the peak levels typically seen in spaceflight hard- 
ware. Since the types of parts used in NIM/ CAMAC equipment are physically 
similar to space-qualified parts, we do not expect internal part failures to 
be a concern. The only components that might be susceptible to the predicted 
peak accelerations are electromechanical devices such as switches, circuit 
breakers, relays, and crystals. With the exception of switches, such devices 
are only rarely used in NIM/CAMAC equipment. 
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The overall result of the dynamic analysis is that the calculated stresses, 
deflections, etc. are all below the levels that are typically encountered in 
spaceflight equipment. Therefore, only relatively minor structural modifica- 
tions should be required to make NIM/CAMAC equipment compatible with the 
Spacelab dynamic environments. This conclusion is further strengthened by 
the fact that the random vibration level actually used in the analysis is 
well above the most recent expected value (see Section 1.2.2). 

1.3.2 Thermal Analysis 

The thermal analysis addressed the use of NIM/CAMAC equipment in the 
forced-air, convective-cool ed environment of the Spacelabe module experiment 
racks. The primary purpose of the analysis was to determine the following: 

• the forced convective heat transfer coefficient as a function of 
air flow rate and location on the printed circuit boards, 

• the maximum board temperature as a function of air flow rate and 
power dissipation, 

• the maximum part case temperature as a function of power density 
and air flow rate. 

In addition, the air flow distribution system for the rack-mounted equipment 
was reviewed, and test techniques were recommended. The analysis is des- 
cribed in detail in TRW Report 7517.1-348, "Thermal Study of NIM/CAMAC Rack- 
Mounted Experiment Equipment for Spacelab Application," April 6, 1976. 

1.3. 2.1 System Configuration 

The crate or bin of the NIM and CAMAC systems contains equipment modules 
with their electronic parts mounted on printed wiring boards, and the modules 
are installed vertically into slots in the housing structure. Openings are 
provided on the top and bottom housing structures next to the boards. For 
Spacelab applications, an air flow distribution plenum is located on the top 
of the housing (see Figure 1-9). The crate or bin is mounted inside a rack 
(cabinet), and is connected to the distribution duct located in the back of 
the rack with flexible connections (see Figure 1-10). 

According to the Spacelab Payload Accommodations Handbook, cooling of 
the crate or bin is accomplished by suction pressure in the following manner. 
Each rack is connected to the avionics loop supply duct and return duct, 
which are located under the floor of the module housing the racks. Air enters 
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Figure 1-10. Spacelab Rack-Mounted Equipment Forced-Air Cooling System 
Cooling System 





the rack from the supply duct, flows through the crate(s) or bin(s) from the 
bottom to the top, exits from the distribution plenum, and is then sucked 
through the distribution duct to the return duct. Each inlet to the distri- 
bution duct contains an adjustable orifice that is used to control the air 
flow through the connected crate or bin according to its needs. Unused in- 
lets are capped off. 

The cooling air flow distribution system described herein appears to be 
feasible. However, in order to achieve an equal quantity of air flow among 
the boards, the air flow distribution plenum must be designed properly. 
Detailed design of the plenum was beyond the scope of this study. 

1 . 3 . 2 . 2 Thermal Analysis Assumptions 

The basic assumptions employed in the analysis are listed below. The 
first two defined critical parameters of the Spacelab cooling system that 
had not been fixed when the analysis was started. The rest of the assump- 
tions were made to simplify the analysis. 

• Cooling air temperature is 23 °C (74 °F) inlet and 40 °C (104 °F) 
exit. 

• Standard cooling air flow rate is 21.8 kg/hr (48 Ib/hr) per 100 watts 
of puwer dissipation. 

• All boards receive the same quantity of cooling air. 

t All boards dissipate the same amount of power. 

• The power dissipations are uniformly distributed on the boards. 

• The total surface area of all parts mounted on a board equals the 
surface area of one side of the board. 

• The convective heat transfer coefficient of the parts equals that 
of the board to which the parts are mounted. 

• Steady-state thermal and air flow conditions prevail. 

• The boards are 28 cm (11 inches) wide x 20 cm (8 inches) high. 

• The effective air flow spacing between the boards is 13 mm (0.5 inch) 
for the crate and 25 mm (1.0 inch) for the bin. 

1 . 3 . 2 . 3 Convective Heat Transfer Coefficients 

From Figure 1-9, it is seen that the air flow spacing between the boards, 
formed by two adjacent boards and the front and back panels of the crate or 
bin, resembles a rectangular duct. The convective heat transfer coefficient, 
h, as a function of air flow rate and board location is shown in Figures 1-11 
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CONVECTIVE HEAT TRANSFER COEFFICIENT h 
(I?TU/Hr-Ft2-«F) 



Figure 1-11. Convective Heat Transfer Coefficient as a Function of Air Flow 
Rate and Board Location for Crate 


CONVECTIVE HEAT TRANSFER COEFFICIENT h 
(BTU/Hr-Ft2-*’F) 



Figure 1-12. Convective Heat Transfer Coefficient as a Function of Air Flow 
Rate and Board Location for Bin 


and 1>12. The coefficient, h, decreases rapidly with increasing flow length, 
X, and the difference between the h values in the middle of the board and 
near the exit (top of the board) is insignificant. 

For a given air flow rate, power dissipation, and board location, there 
is a fixed temperature difference, AT, which consists of two components: 
one component, AT, is from the boa'^d or part case to the cooling air, which 
is due to heat transfer from the surface to the air. The other component, aT, 
is due to increase in the enthalpy of the cooling air, as the air absorbs the 
heat. 

These AT's change in value from inlet to exit, and the maximum value 
occurs near the exit where the coefficient, h, is minimum and the enthalpy 
is maximum. Since the worst-case maximum temperature dictates the design, 
the maximum aT's were calculated and were added to the air inlet temperature 
of 74 °F to obtain the maximum board temperature. 

In looking over photographs of the NIM/CAMAC equipment printed wiring 
boards with parts mounted on them, it was observed that most parts are DIP'S 
(Dual In-line Packages) and the packaging density is such that the surface 
area of the parts approximately equals or is somewhat less than the area of 
one side of the board. The parts are usually separated from the board by a 
gap of 0.020 inch and the boards are not conformal coated. The parts are 
exposed to the cooling air, and the convective heat transfer coefficients of 
the parts are generally equal to or higher than that of the board (depending 
on the orientation of the parts with respect to the air flow direction). In 
general , the temperature difference between the case and the board tends to 
be insignificant. Therefore, for practical purposes, the case temeprature 
was considered equal to the board temperature. 

1 . 3 . 2 . 4 The rmal Analysis Results and Conclusions 

The principal results of the thermal analysis are presented in the four 
graphs shown in Figures 1-13 to 1-16. These graphs show the relationship 
between maximum board or part case temperature, power dissipation and air 
flow rate for the CAMAC and NIM configurations. The results are presented 
in parameteric form to allow their use in analyzing a variety of specific 
cases. Our overall conclusions are based on the average or nominal situation. 
Several examples to illustrate the use of the results for specific cases are 
also given. 


31 


MAXIMUM BOARD TEMPERATURE T, 


■ i H * i M M- 

» - *- f t-t — I t 

. 4 t I : * i ' 


« i4 


: II I ;i 

; ^ j j I 


-U ^4-1 

+Ttt4rm' 

-I : : i : iit4 

■ t ; t I t' f 4^ 

, t 4 . I 4-1 |4- 
, 1 f4 ^ 1 -4 1 I 
: : : 


l- 


NOTES: 1. Effective air flow spacing 

between boards Is 0.5 Inch. 

2. Boards are 11 Inches wide 
X 8 Inches high. 

3. Power dissipation Is uniformly 
distributed on the board. 

4. Air temperature Is 74*F Inlet 
and 104®F exit. 

5. Standard air flow rate Is 0.48 
Ib/hr-watt. 

6. Average temperature Is approx. 

; 15®F lower than max temp shown. 
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NOTES: 1. Effective air flow spacing 
between boards Is 1.0 Inch. 

2. Boards are 11 Inches wide 
X 8 Inches high. 

3. Power dissipation Is uniformly 
distributed on the board. 

4. Air temperature Is 74“F Inlet 
and 104*F exit. 

5. Standard air flow rate Is 
0.48 Ib/hr-watt. 

I 6. Average temperature Is approx- 
I Imately 15*F lower than 

! maxlnun temperature shown. 



POWER DISSIPATION 
PER BOARD Q (WATTS) it: 










POWER DISSIPATION 
*it CONSISTENT WITH 
STANDARD AIR 
#~FL0W RATE 

ir^HiHHioo 






■t iH-f ‘ -rrt 


TSCtoToTT 


, 1 1 i , , 

Lll j_U P-80 




I ^4 .-(-^- 4 - 4 -;-+ , 




^ 7.0 -*- 4 - 




:r.t: : 


l-.TTt-4:- 




-*■ r * i * ^ -t- -'f- • • * -r 

T^. rttttiSTt 4 ;::.Ui44::i 4T4: r: n: 






f 4- • r -♦"T--*- 

H -4— f — 4 -•.-4-4 A— — ^4-* '4-t -f ^ — 1"“ *■* — * I 
4_44 4-^J-4--i. -*_4.4 -*-i -K-.. , 


4.i_4TTt= 


-^-^4444- 




AIR FLOW RATE iJ (Ib/hr) 

Figure 1-14. Maximum Board Temperature as a Function of Air 
Flow Rate and Power Dissipation for Bin 
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between boards Is 0.5 Inch. 
Boards are 11 Inches wide 
X 8 Inches high. 

Power dissipation Is uniformly 
distributed on the board. 

Air temperature Is 74*F Inlet 
and 104®F exit. 

Standard air flow rate Is 0.48 
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Figure 1-15. Maximum Case Temperature as a Function of Power 
Density and Air Flow Rate for Crate 
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Figure 1-16. Maximum Case Temperature as a Function of Power 
Density and Air Flow Rate for Bin 
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Overall Conclusions - The average power dissipation in a commercial CAMAC 
module is about ten watts. From Figure 1-13, we see that at the standard 
Spacelab air flow rate, the maximum board temperature, assuming uniform power 
dissipation in the module, will be 61 °C (142 °F). Therefore, the maximum 
operating case temperature for industrial grade parts (70 °C) is not exceeded. 
However, the margin is not very great. A twenty-five percent increase in 
either local power dissipation (see Figure 1-15) or total module power dissi- 
pation will increase the maximum temperature to the limit of 70 °C. If the 
maximum allowable temperature is increased to 125 °C (257 °F) by using military 
grade parts, the air flow rate can be reduced to under one-half of the standard 
value while still maintaining a comfortable margin on the part temperatures. 
Obviously, the most effective modification from a thermal standpoint would be 
to reduce the power dissipation by using low-power versions of the parts that 
are functionally acceptable. If the average module power dissipation were 
reduced to five watts, the flow rate could be halved and the maximum tempera- 
ture of 50 °C (122 °F) would be well below the limit on Industrial grade parts. 
Careful attention to any residual high-powe^- parts would be needed, since 
they would be points of high local power dissipation and, hence, hot spots. 

The average power dissipation in a NIM module is about six watts. From 
Figure 1-14, it can be seen that the nominal situation is very similar to the 
CAMAC case. The fact that the thermal situation is not better for NIM than 
CAMAC is due in large part to the last assumption listed in Section 1.3. 2. 2. 

The wider effective duct width for the NIM module results in a less efficient 
use of the cooling air flow (compare Figures 1-11 and 1-12). 

Modification of the module top and bottom covers to concentrate the air 
flow on the internal circuit boards would tend to equalize the convective 
heat transfer coefficients for the two cases. 

Illustrative Examples - 

Example 1: A crate containing 25 boards dissipates a total of 250 watts, and 
is cooled by air at an inlet temperature of 74 °F. Assuming all boards dissi- 
pate the same amount of heat and uniform heat distribution on the boards, 
determine the maximum board temperature if the cooling air flow rate is 
(a) standard, (b) 50 percent of standard, and (c) 150 percent of standard. 
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Power dissipation per board Q = 250 watts/25 boards 

= 10 watts/board. 

From Figure 1-13, Note No. 5, standard air flow rate is 0.48 Ib/hr-watt, 
W = 0.48 Ib/hr-watt x 10 watts = 4.8 Ib/hr. 


From Figure 1-13, for Q = 10 watts/board, 


W = 4.8 Ib/hr, T 
W = 2.4 Ib/hr, T 
W = 7.2 Ib/hr, T 



Example 2: An 11-inch wide x 8-inch high printed wiring board, with 16 lead 
dip's mounted on it, is to be used in a crate. The board has a total power 
dissipation of ten watts, and is to be cooled with 74 °F air at a rate of 
4.8 Ib/hr. Assuming all parts dissipate the same amount of power and have 
the same heat transfer coefficient, determine the part case temperature if 
the packaging density is such that (a) the total surface area of all parts 
equals the board area; (b) there are 12 rows of 13 parts each; and (c) there 
are 17 rows of 7 parts each. 

For average cases, such as the example given herein, heat transfer from 
the part surface that faces the board may be assumed negligible, since there 
tends to be low air flow through the small gap (0.020 inch) between the part 
and the board. Also, heat transfer from the leads may be assumed to be 
negligible due to the small surface area of the leads, although the heat 
transfer coefficient over the leads may be high. These simplifying assump- 
tions should yield slightly higher temperatures, which is a conservative 
approach. However, for extreme cases with high power dissipation, every pos- 
sible heat path should be included. 

Vrts = ^oard = ^ 8 = 88 (a) 

1 = --- K = 0.114 W/in^ = 114 mW/in^ 

^parts 88 in^ 

From Figure 1-15, T„^„^ = 142 °F . 

— 
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(b) 


Vrts " ^ 2(0.725 x 0.160) 

+ 2(0.265 X 0.160) = 0.509 in^/part 

2 

Apa^ts “ ^ parts/row x 0.509 in /part 

=79.4 in^( total) 


From Figure 1-15, T = 149 °F . 

‘^“®tnax 


2 

Aparts " rows x 7 parts/row x 0.509 in /part 
= 61 .0 in^( total ) 


(c) 


parts 61 in 
From Figure 1-15, T 


= 0.164 W/in^ = 164 mW/in^ 


case, 


= 173 °F . 


max 


The foregoing example shows the importance of surface area. For the same 
power dissipation and air flow rate, the temperature increases as area de- 
creases, and vice versa. Also, when the total surface area of all parts 
equals the board area, the case temperature equals the board temperature for 
the same air flow rate and heat load as indicated in Examples 1(a) and 2(a). 

It should be alerted that, when using Figures 1-13 and 1-14, one must pay 
attention to the difference between the total part surface area and board 
area, because for a reduction in area of 31 percent (from 88 in to 61 in ), 
the temperature increased 31 °F (from 142 °F to 173 °F) [see Examples 1(a) 
and 2(c)]. If one knows that the total part surface area is less than the 
board area, he should use Figures 1-15 and 1-16 instead of Figures 1-13 and 
1-14 to estimate the temperature, as was done in Example 2. 

The study considered mainly the ideal case with the heat load uniformly 
distributed on the board. For less ideal cases, such as heat load concentrated 
on the left or right half of the board, or the upper or lower half of the 
board, the results developed for the ideal case can be used to estimate the 
temperatures with sufficient accuracy when simple factors are applied, as 
shown in Figure 1-17 and the following example: 


CASE 


CASE 


CASE 


1 . 


Heat Load Uniformly Distributed on the Board: 

EXIT 



USE CURVES AS THEY ARE 


2. Heat Load Concentrated on Left or Right Half of the Board: 

EXIT 



USE CURVES FOR 


3, Heat Load Concentrated on Upper or Lower Half of the Board: 

EXIT 



USE CURVES FOR Qeffective = 
AND ADD 20°F TO T^^^^ OBTAINED 


Figure 1-17. Cases for Uniformly Distributed and Concentrated 
Heat Load Conditions 
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Example 3: Same as Example 1 except instead of uniform heat distribution, hnat 
is concentrated on the (a) left half of the board; and (b) upper half of the 
board. Determine the maximum board temperature for a cooling air flow rate 
of 4.8 Ib/hr (standard). 

From Figure 1-17, Case No. 2, determine the temperature by using (a) 

the curves for Qeffgctive = 

From Figure 1-13, for Q = 2 x 10 = 20 W, = 210 °F. 

max 

From Figure 1-17, Case No. 3, determine the temperature by using (b) 

the curves for Q . = 1 . 5 Q and add 20 °F to the temperature 

so obtained. ertective 

From Figure 1-13, for Q = 1 .5 x 10 = 15 W, = 176 x 20 = 196 °F . 

max 

1.3. 2. 5 Recommendations for the SECT Program 

As part of the thermal analysis effort, more definitive recommendations 
for thermal testing in the SECT program at OSC were generated. The objec- 
tive of the tests, as described here, is to simulate the Spacelab environment 
for rack-mounted equipment. The recommended configuration is shown in 
Figure 1-18. The equipment will be operated in a laboratory ambient environ- 
ment with ambient air sucked through it to provide cooling. An air distri- 
bution plenum, with a long flexible duct attached to it, will be installed 
on top of the crate. Located near the other end of the flexible duct is a 
fan, which will be utilized to suck the air through the crate. 

For this test, the following measurements should be performed: 

• Total electrical power input to the crate, and if possible, power 
input to some typical and high-power boards (same boards whose 
temperatures are to be measured) . 

w Temperatures of typical and high-power boards and parts mounted on 
them; at least two boards located in the middle and two boards on 
one side of the crate, and the high-power dissipating and low-power 
dissipating parts. 

0 Total cooling air flow rate through the crate, and preferably air 
flow rates over typical and high-power boards, as well as the 
middle and side boards (whose temperatures are to be measured). 
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AIR OUT 



Figure 1-18. Recommended Test Techniques for Thermal Testing of 
NIM/CAMAC Experiment Equipment 



Every attempt should be made to measure the power dissipations of the 
boards, because without knowing the values of this parameter, comparison of 
the test and analytical results would not be meaningful. 

For temperature measurements, it is recommended that thermocouples be 
bonded to the boards and parts with a thermally conductive epoxy. 

To determine the total air flow through the crate, an inclined water 
manometer can be used to measure the static pressure across the fan, and from 
the fan characteristic curve, the volume air flow rate can be determined. 

In order to calculate the weight air flow rate, the air temperature upstream 
of the fan should be measured, from which the density of air can be deter- 
mined. It is desired to test the equipment at the following air flow rates: 
(a) standard, (b) 50 percent of standard; and (c) 150 percent of standard. 

The air flow rate can be varied with a damper that should be located down 
stream of the fan. ■ 

The adequacy of the air distribution plenum can be determined by mea- 
suring the air flow rates over the boards that are located near the middle 
and near one side of the crate. Calculations showed that the air velocity 
over the boards is approximately 30 ft/mi n, and in order to measure this 
low velocity with sufficient accuracy, it is recommended that hot-wire ane- 
mometers should be located in the exit openings (upper structure of the crate 
which keeps the boards in the vertical position), where the area can be 
measured accurately. The air temperatures at the same locations should be 
measured with thermocoupl es , which allow the determination of the density 
of air. Finally, the weight air flow rate can be determined by the equation 
of continuity. 
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1.4 RECOMMENDED MODIFICATIONS AND ESTIMATED COSTS 

(TASK 3B) 

1.4.1 Reconmended Modifications 

The preliminary assessment of the modifications that would be required 
to make NIM/CAMAC equipment compatible with the Spacelab environments, pre- 
sented in Section 1.2.3, was reevaluated in light of the results of our 
dynamic and thermal analyses to arrive at our final recommendations for equip- 
ment modifications. The modifications are treated in two categories. First, 
we will consider the minimum modifications that are required to use NIM/CAMAC 
equipment with at least some degree of confidence in its reliable operation. 
Second, we will consider those modifications that would essentially assure 
reliable operation. At the same time, these more extensive modifications 
will allow the incorporation of the changes needed to alleviate the convec- 
tive cooling requirements of NIM/CAMAC equipment. 

1.4. 1.1 Module Modifications 

In general, the minimum modifications required correspond to the pre- 
liminary assessment except in the area of structural changes where the 
situation was found to be better than our intuitive judgment indicated. 

The minimum module modifications required are given in Table 1-5. They 
apply to both NIM and CAMAC modules, with the few exceptions noted. These 
modifications are all of the type that could be performed on a commercial 
module after its original fabrication with the possible exception of the 
isolation of circuit and frame grounds. Changes in the printed circuit 
board layout, which are difficult to implement after the fact, may be re- 
quired to obtain ground isolation. 

The second class of modifications considered for NIM and CAMAC modules 
are more extensive and involve a significant amount of redesign prior to 
module fabrication. These modifications could not be performed on commercial 
modules after their original fabrication. The general approach would be the 
following: starting with the existing circuit design, perform design and 
reliability analyses directed at reducing power consumption, replacing com- 
mercial electronic components such as parts and connectors with items 
selected from a NASA-approved parts list, and increasing the circuit relia- 
bility under worst-case conditions. Once the circuit redesign is completed. 
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Table 1-5. Minimum Modifications Required for 
NIM and CAMAC Modules 


• Conformally coat the printed circuit boards. 

• Mechanically support or spot bond unsupported parts weighing more than 
five grams and vunerable parts such as vertically-mounted capacitors. 

• Stress relieve and spot bond point-to-point wiring. 

t Lock all fasteners by spot bonding or substituting self-locking hardware. 

• Isolate circuit ground from frame ground. 

• Review materials (especially plastics) and replace with acceptable 
materials; e.g., Teflon-insulated wire. 

t Analyze power dissipation to identify local hot spots. Correct by instal- 
lation of heat sinks or replacement with extended temperature range part. 

a Inspect soldering and lead forming on parts. Rework or replace suspect 
items as required. 

a Install top front panel attachment screws on all CAMAC modules. 

a Install guide pins to provide mechanical support for the rear card edge 
connectors on all CAMAC modules. 

a Review electromechanical devices such as switches, potentiometers, etc., 
and replace with vibration-qualified devices or hard-wired parts. These 
devices are mostly found in NIM modules. 

a new product design, primarily involving a modified printed circuit board 
layout, would be performed. Again, this board layout would presumably start 
with the existing layout and incorporate both the circuit and component changes 
as well as the modifications identified as minimum modifications in Table 1-5. 
The fabrication of the redesigned module would be done in conformance with 
current NASA-approved processes and assembly techniques for space electronics. 
The inspection and test activities would also be handled in much the same 
way as they currently are for experiment electronics to be flown on unmanned 
scientific spacecraft. 

This approach to implementing NIM and CAMAC equipment for spaceflight 
experiments is being actively pursued by NASA/GSFC. Three manufacturers of 
commercial CAMAC and NIM equipment are each investigating this type of approach 
for several specific modules under contract to GSFC (see Table 1-Z, Volume 11), 
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One of the objectives of the GSFC work is to reduce the power dissipation to 
the point at which conduction cooling of the spaceflight versions of NIM/ 
CAMAC equipment is possible. If this is feasible, some further mechanical 
changes to the modules will be required to improve the heat conduction paths 
inside the modules and from the modules to the crate or bin. These changes 
would be incorporated into the new product design for the modules discussed 
in the preceding paragraph. 

1.4. 1.2 Crate or Bin Modifications 

The minimum modifications that must be made to the CAMAC crate or NIM 
bin correspond very closely to our preliminary assessment. The essential 
result of the dynamic analysis was to confirm that the basic structure was 
adequate with a comfortable margin of safety. The minimum crate/bin modifi- 
cations required are listed in Table 1-6. 

Table 1-6. Minimum Modifications Required for 
NIM Bins and CAMAC Crates 

0 Provide bottom surface mechanical support and attachment to Spacelab 
rack structure. 

0 Provide top surface plenum with connection to the Spacelab cooling air 
return ducts. 

0 Lock all fasteners by spot bonding or substituting self-locking hardware. 
0 Add retaining mechanisms to all card guide rails. 

0 Add attachment points for module top front panel screws (already on NIM 
bins and some CAMAC crates). 

0 Provide guide pin sockets for CAMAC dataway connectors. 

As was discussed in Section 3 of Volume II, because of the inherent 
high degree of commonality present in the requirements for system-common 
equipment, such as the crates or bins, a reasonable effort can justifiably 
be invested in developing spaceflight versions of the equipment. This is 
not particularly significant so far as the crate mechanical structure is 
concerned because the existing design is basically adequate. However, this 
point has a very significant influence on the choice of the best approach 
for the crate or bin low-voltage power supply. The most reasonable approach 
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is to design, develop, and qualify a crate low-voltage power supply speci- 
fically for Spacelab use. The redesign would be primarily directed at 
increasing the supply efficiency and reducing the supply weight. If a suf- 
ficient weight reduction is achieved, the supply could be mounted on the 
rear of the crate or bin as it is in the existing equipment. Otherwise the 
supply could be independently mounted to eliminate the large cantilevered 
load on the rear of the crate or bin. 

To a large extent, this approach corresponds to going directly to the 
second category of more extensive type modifications discussed in the pre- 
vious section for modules. Again, if it turns out to be feasible to reduce 
the power consumption to the level at which conductive cooling can be con- 
sidered, more extensive mechanical modifications to the crate will be needed 
to improve the thermal conduction paths. 

1.4.2 Modification Costs 

In estimating the modification costs, we have taken advantage of the 
inherent commonality of NIM and CAMAC equipment. The types of modifications 
that have to be performed are relatively independent of the particular func- 
tion or supplier of the module. Therefore, we have estimated the modifica- 
tion cost for an average single-width module (i.e., containing one printed 
circuit board). As a point of reference, the current average retail price 
of NIM or CAMAC modules is about $700. 

The actual modification cost for any particular module may vary consider- 
ably from the average cost we have estimated depending on the complexity of 
the unit and the amount of modification needed (see, for example, the results 
of the GSFC-sponsored studies by three CAMAC manufacturers). However, the 
principal use of our cost estimates will be to. generate programmatic cost 
estimates in Task 4. As will be seen in the discussions of Task 4, the num- 
ber of modules involved in the programmatic estimates is large. Thus, to 
well within the overall accuracy of the programmatic cost estimates , any 
variations in actual modification costs for different types of modules will 
average out. 

Cost estimates were developed for three cases. The first two correspond 
to the minimum modification approach and the more extensive modification 
approach discussed in the previous section. The third case deals with a 
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so-called custom-built approach that corresponds closely to current aerospace 
practice for the development of unmanned spaceflight experiment electronics. 
This case is included for the purpose of comparing the cost of using modified 
NIM/CAMAC equipment for Spacelab payloads with the cost of continuing to use 
current methods of implementing payload electronics. 

Since the crates and bins, with their associated power supplies, consti- 
tute a small fraction of the projected equipment usage (less than seven per- 
cent), no separate cost estimate was generated. As discussed in Section 
1.4. 1.2, the best approach for these equipment items is a one-time develop- 
ment of a version specifically designed for spaceflight use. Although the 
powered crate or bin is a distinctly different type of hardware compared 
with the modules, the development and production costs are not expected to 
be sufficiently different from the module costs to significantly affect the 
overall programmatic cost estimates. 

1.4. 2.1 Minimum Modification Costs 

The minimum modifications needed to adapt NIM/CAMAC modules for Spacelab 
use (see Table 1-5) are essentially identical to the type of modifications 
identified in the Rockwell analysis of commercial equipment for Spacelab pay- 
loads. Therefore, the Rockwell cost estimates have been used as the basis 
for our minimum modification cost estimates. The basic approach investigated 
by Rockwell involved modification of an actual commercial unit after its 
original manufacture. As stated in Section 1 .4.1 .1 , this approach is appli- 
cable for what we call minimum modifications. 

In the Rockwell study, a wide variety of commercial equipment that was 
likely to be used in Spacelab payloads was analyzed. Four items of NIM equip- 
ment were included in the analysis. Two of the items, the NIM bin power 
supply and the Nuclear Data multichannel analyzer, are not good representa- 
tions of NIM/CAMAC modules. Although the multichannel analyzer contained 
three NIM modules, the majority of the hardware was not NIM and the module 
modification costs were not separately identified. In the case of the two 
other items, the Tennelec timer consisted of three NIM modules and the ORTEC 
particle counter consisted of four NIM modules. 

A certain amount of analysis and interpretation was necessary to extract 
module modification costs from the Rockwell report in a suitable form for our 
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purposes here. Most importantly, the nonrecurring engineering and test costs 
estimated by Rockwell for the items composed of several NIM modules took iritc 
account the fact that the individual modules are very similar. Our interpre- 
tation of their cost estimates for the Tennelec timer and the Ortec particle 
counter is that the engineering and test costs are independent of the nunpe»' 
of individual modules in the equipment. It is generally true of the Rockwell 
modification cost estimates that the engineering and test costs are relative'/ 
insensitive to the retail price and complexity of the equipment. Therefore, 
we have taken the mean of the engineering and test costs for the Tennelec 
timer and the Ortec particle counter as the best estimate for a single module. 
It is certainly true that in actuality advantage would be taken of the con- 
tiionality of NIM/CAMAC equipment to reduce the modification costs. However, 
for consistency, all of our cost estimates are based on the assumption that 
each module is treated independently since we cannot see a nonarbitrary v^ay 
of choosing, at this point, how many modules would be modified by one 
organization. 

The best estimate of the average manufacturing cost per module is 
straight forward. The total manufacturing cost for the Tennelec timer and 
the Ortec particle counter was divided by seven, the number of modules in- 
volved. For documentation and program management, Rockwell ratios of ten 
percent and five percent, respectively, of engineering, manufacturing and 
test were used. Finally, the costs were divided into nonrecurring design, 
development, test and engineering, and recurring unit costs. The Rockwell 
test category includes the costs associated with development verification 
testing of the first unit which is basically nonrecurring whereas the cali- 
bration and testing of subsequent units is included in the manufacturing 
costs. 

The resulting cost estimate is shown in Table 1-7. A check on our 
interpretation of the Rockwell cost estimates can be obtained by comparing 
the ratio of the modification cost to the retail unit cost in Table 1-7 with 
the summary plot of this quantity versus retail unit cost for HIM c-quipment 
shown in Figure 3-33 of Volume II of the Rockwell report (511,513/695 - 16.5 
from Table 1-7 compared with 16 for a retail unit cost of $700 in Figure 3-33). 
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Table 1-7. Estimated Costs of Minimum Modifications 
for an Average NIM/CAMAC Module 
(adapted from Rockwell study) 



Nonrecurring 

Recurring 

Engineering 

5,850 

-- 

Verification Test 

3,680 

__ 

Manufacturing and Test 

- 

485 

Documentation 

953 

49 

Program Management 

477 

24 

Original Module Cost 

- 

695 

Totals 

$ 10,960 

$ 1 ,253 


1.4. 2. 2 More Extensive Modification Costs 

Our estimated costs for the more extensive approach to modification for 
Spacelab use, described in Section 1.4. 1.1, were derived from a recent TRW 
study of low-cost approaches to scientific experiment implementation for 
Shuttle-launched and serviced spacecraft (Contract NAS w-2717). As part of 
that study, a cost was computed for producing standard electronic modules 
that were similar to NIM and CAMAC modules in function and complexity, but 
designed specifically for spaceflight use. The costs were generated using 
detailed cost estimating relationships based on our experience with developing 
spaceflight scientific experiment electronics. The costs are broken out in 
accordance with a rather detailed work breakdown structure. 

The cost estimate for the modification approach under consideration here 
was developed by modifying the level of effort devoted to each of the tasks 
in the work breakdown structure to correspond to the modification approach 
discussed in Section 1.4. 1.1. The important changes to the "low-cost approaches 
study" estimate for development of a standardized electronic module were: 

t Start from existing circuit design and printed circuit board layouts. 

• Reduce number of qualification units produced and extent of the 
qualification test program. 

• Concentrate reliability effort into parts selection and application 
review, worst-case analysis , and test requirements. 
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The resulting cost estimate is shown in Table 1-8, broken down into major 
task categories as well as nonrecurring and recurring costs. 


Table 1-8. Estimated Costs for More Extensive 
Modifications to an Average 
NIM/CAMAC Module 


Nonrecurring Recurring 
Design Engineering 10,750 


Product Engineering 7,500 

Reliability .2,500 

Parts, Materials and Processes 4,000 2,900 

Qual ity Assurance 3,750 400 

Manufacturing 13,630 1,150 

Test 7,000 380 

$ 49,130 $ 4,830 


1.4. 2. 3 Custom-Built Module Costs 

This case does not actually correspond to modification of an existing 
NIM/CAMAC module, but rather represents the costs required to develop and 
produce an equivalent unit using a conventional, present-day approach for 
experiment electronic hardware intended for use on an unmanned scientific 
satellite. The unit is equivalent in the sense that it satisfies the same 
functional requirements as the NIM/CAMAC module. Our cost estimate for this 
case is taken directly from the TRW low-cost approaches study discussed in 
the previous section. The module cost estimate generated in that study is 
applicable without any adjustment. 

The cost estimate, broken down into major task categories and nonrecur- 
ring and recurring costs, is given in Table 1-9. 
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Table 1-9. Estimated Costs for a Custom-Built 
Equivalent of an Average NIM/CAMAC 
Module 


Nonrecurring 

Recurring 

Design Engineering 

27,500 

- 

Product Engineering 

12,500 

- 

Rel iabi 1 ity 

6,250 

- 

Parts, Materials and Processes 

23,375 

3,150 

Quality Assurance 

12,500 

590 

Manufacturing 

34,125 

2,130 

Test 

8,750 

380 

Totals 

$ 125,000 

$ 6,250 


1.4.3 Analysis of Alternative Modified Equipment Sources 

In their analysis of commercial equipment for Spacelab payloads, Rock- 
well reached the conclusion that the original manufacturer is clearly the 
preferred modifier. In the particular case of NIM/CAMAC equipment being 
considered here, we came to essentially the same conclusion for many of the 
same reasons. However, the choice is not as clear. For NIM/CAMAC equipment, 
some of the factors to be considered in determining the most cost-effective 
source differ significantly from the general case analyzed by Rockwell. 

The extremely nonuniform procurement profile used by Rockwell (large 
peaks every five years) almost immediately ruled out any centralized agency 
bpcause of the inefficient utilization of personnel and facilities. As we 
will see in the discussion of Task 4A to follow, the procurement profile 
for NIM/CAMAC equipment is reasonably constant. In addition, if an equip- 
ment pool is adopted, a central agency that has other related functions to 
perform already exists. 

Secondly, the inherent commonality of NIM/CAMAC equipment due to its 
standardized nature reduces the advantage the original manufacturer has 
because of his familiarity with his own equipment. 

Finally, a centralized source could take greater advantage of the com- 
monality in the kinds of modifications that are required to reduce the non- 
curring costs involved. Recall that in the discussion of modification costs 
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in Section 1.4. 2.1, it was pointed out that, whereas our cost estimate 
assumed independent efforts for each type of module, in actuality, nonrecur- 
ring costs should be lower when more than one type of module was being modi- 
fied by the same organization. Obviously, the greater the number of modules 
being handled in common, the greater the cost reduction. 

On the other hand, due to the many types of NIM/CAMAC modules being used 
and the fact that mo'st of the manufacturers each produce all or most of the 
types, many more than one type of module would usually be supplied by a 
particular manufacturer in any case. 

In addition, the original manufacturer still has many advantages in 
terms of familiarity and available facilities and stock. This is especially 
true for the case of minimum modifications. Most importantly, he can incor- 
porate the modifications during the original manufacturing cycle, as opposed 
to after the fact, and, hence, avoid the costs of disassembly, discarded com- 
ponents, retesting, etc. For the case of minimum modifications, our conclu- 
sion is that incorporation of these modifications during the original 
manufacture of the equipment is the most cost-effective approach. 

For the case of the more extensive modifications, the modifications 
clearly must be incorporated during the unit fabrication and assembly. The 
only question is whether the most cost-effective manufacturer is the manu- 
facturer of the commercial unit on which the redesign was based or someone 
else. The current U. S. suppliers of NIM and CAMAC do not produce military 
or aerospace equipment (the same is not true of the European suppliers). 
Therefore, they have the disadvantage of not having the special facilities 
for, or experience with, the production of aerospace equipment to military 
or NASA standards. 

In this case, their willingness to learn the practices, procedures, and 
techniques required becomes a key factor. The willingness of at least some 
of the NIM/CAMAC suppliers to do So has been demonstrated by the GSFC-sponsored 
activities. Assuming this interest and willingness continues, they may well 
be the most cost-effective source. On the other hand, the alternative source 
of a contractor with experience in producing aerospace electronics, possibly 
gaining access to the original supplier's familiarity with the equipment 
through a licensing agreement, would probably not be significantly less cost- 
effective. 
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2. IMPLEMENTATION ANALYSIS AND MANAGEMENT PLAN DEVELOPMENT 
FOR NIM/CAMAC EQUIPMENT (TASK 4A) 

2.1 INTRODUCTION 

The study effort to this point has demonstrated the general applicability 
of NIM and CAMAC equipment for Spacelab payloads and has defined the necessary 
modifications and costs involved to make NIM/CAMAC equipment compatible with 
the Spacelab environment. In this task, we used these results to estimate 
the projected usage and costs of NIM/CAMAC equipment in Spacelab payload opera- 
tions during the time period of 1980 to 1991. 

Two alternative general approaches to providing the NIM/CAMAC equipment 
required for Spacelab payloads were considered. 

9 A shared-equipment implementation in which the various Spacelab 
users draw their required complement of standard NIM/CAMAC equip- 
ment for a given flight from a common equipment pool. 

9 A dedicated-equipment implementation in which each of the users 
is responsible for procuring either their own NIM/CAMAC equipment 
or its custom-built equivalent. 

The obvious objective of the shared-equipment approach is to take advantage 
of the commonality found in the NIM/CAMAC requirements of the various pay- 
loads in order to minimize the total amount of equipment, and hence cost, 
needed to support the Spacelab payload operations. The basic assumption, 
which makes this approach attractive to consider, is that by committing the 
NIM/CAMAC equipment needed in a particular payload to that payload for only 
the length of time it is actually required for a given flight, the overall 
efficiency of equipment utilization will be significantly increased. 

Experience with NIM/CAMAC use in ground-based laboratories strongly in- 
dicates that an equipment pool is a cost-effective method of satisfying user 
requirements for standard modules in a situation that has many factors in 
common with Spacelab payload operations. A simplified version of the situa- 
tion for Spacelab payloads has already been considered in the commonality 
analysis of Task 2 (see Section 3.9.2, Volume II). Comparison of the extreme 
casesi namely, completely shared equipment usage in a serial flight series 
of the eleven representative payloads versus completely dedicated usage in a 
parallel flight series, indicated that equipment sharing between payloads 


53 



would reduce the total amount of equipment required from 687 items to 217 
items, in the case of CAMAC equipment; and from 406 items to 245 items, 
in the case of NIM equipment. Thus, an overall reduction by a factor of 
about 2.4 was obtained in this overly simplistic scenario. 

Our work in Task 4A was directed at making a more accurate and real- 
istic assessment of the impact of equipment sharing in the Spacelab era. 
Hence, we have concentrated on determining the most efficient type of equip- 
ment pool implementation for Spacelab payloads. However, in order to pro- 
vide a baseline for comparison, we have also estimated the costs of 
dedicated equipment implementation approaches that do not involve a pool. 
Although a number of simplifying assumptions were necessarily made in our 
analysis, we believe that the overall results present a reasonably accu- 
rate projection of the cost reductions that can be achieved through the 
use of NIM/CAMAC in a pooled-equipment implementation approach. In actu- 
ality, many detailed factors will vary from the model used here, but the 
overall results should remain valid. Our approach to Task 4A was sub- 
divided into the following four tasks: 

Task 4A.1 - Develop time-phased NIM/CAMAC equipment requirements. 

9 Define a baseline Spacelab traffic model. 

• Establish a schedule for module use by an individual payload. 

ft Project overall NIM/CAMAC usage in the baseline payload model 
using the results of Task 2 for representative payloads. 

Task 4A.2 - Perform a tradeoff analysis of NIM/CAMAC equipment pool 
concepts. 

ft Define alternative pool concepts. 

ft Tabulate pool size requirements for the alternatives. 

ft Select the optimum pool concept. 

Task 4A.3 - Prepare a management plan based on the recommended pool 
concept. 

ft Refine pool size requirements taking into account equipment 
replacement rates. 

9 Prepare a budgetary cost estimate for pool equipment, 

ft Develop a recommended NIM/CAMAC equipment procurement plan and 
a recommended pool management plan. 
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Task 4A.4 - Prepare comparative equipment cost estimates for program 
implementations that do not involve a pool approach. 

• Tabulate equipment requirements based on no equipment sharing. 

• Prepare cost estimates based on nonshared NIM/CAMAC equipment 
and on nonshared custom equipment. 

The first three tasks will result in a management plan for the recom- 
mended pool concept. The fourth task will provide the information neces- 
sary to determine the expected cost savings from implementing an equipment 
poos using NIM/CAMAC equipment. 

The documentation used in the performance of Task 4A is listed in 
Table 2-1. These references were primarily used in our effort to define 
a baseline Spacelab payload flight traffic model that constitutes a reason- 
able representation of the number of Spacelab flights that will occur be- 
tween 1980 and 1991. Because Shuttle mission planning activities are still 
in the formative stages, the payload flight traffic model will undoubtedly 
change. The overall results of our analysis, for the most part, can simply 
be scaled with the total number of Spacelab flights in the model, unless 
the payload mix significantly varies. 

Finally, some definitions of the nomenclature being used here should 
be noted. As previously discussed in Section 2.1 of Volume II, we are 
using the term "payload" to mean a collection of instrumentation that re- 
quires approximately the full resources available in a given Spacelab flight. 
A flight simply means one sequence of the operations (payload integration, 
launch, orbital operations, return, etc.) necessary to carry out a mission 
with a given payload. 

Since it is anticipated that many payloads will be flown more than 
once, with refurbishment and possibly modification between flights, the num- 
ber of flights will always be greater than the number of payloads. For the 
case of equipment sharing, the NIM/CAMAC equipment requirements are deter- 
mined primarily by the number of flights since the equipment is not uniquely 
identified with a given payload. The overall equipment requirements are 
relatively insensitive to variations in the makeup of the payload for any 
particular flight as long as the overall distribution of missions among the 
different disciplines is not changed. 
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On the other hand, the equipment requirements are primarily determined 
by the number of payloads in the case of dedicated use, and the results are 
relatively sensitive to questions such as how many times is a particular 
payload flown without making modifications that result in new requirements 
for NIM/CAMAC equipment. As we will see in Section 2.5, this makes the 
realistic estimation of equipment requirements more difficult in the 
dedicated equipment case. 

Table 2-1. References Used in NIM/CAMAC Management 
Plan Development 

Summarized NASA Payload Descriptions - Sortie Payloads (SSPDA), 
NASA/MSFC, July 1974. 

The 1973 NASA Payload Model - Space Opportunities 1973-1991 , 
NASA/Headquarters, 1973. 

Updated Flight Model for Use in Shuttle, Spacelab, and lUS/Tug 
Procurement and Operations Analysis (Yardley Memorandum), NASA/ 
Headquarers, October 1974, 

Shuttle Era Mission Model - Sortie Payload Missjons/Experlments , 
NASA/GSFC, December 1974. 

Spacelab Briefing for AMPS, NASA/MSFC, November 1975. 

2.2 TIME-PHASED NIM/CAMAC EQUIPMENT REQUIREMENTS 
2.2.1 Baseline Spacelab Flight Traffic Model 

In Task 2 of this study representative Spacelab payloads for a wide 
range of disciplines were analyzed. In order to transform this data into 
a measure of the total requirements for NIM/CAMAC equipment, the Shuttle 
flight frequency for each of the disciplines is required. The selection 
of this flight traffic model is important since the subsequent definition 
of an appropriate pool concept, management plan and program cost is based 
on this model. However, the precise details of the flight traffic model 
are not critical, as the aim of this task is to define the order of magni- 
tude of a NIM/CAMAC pool. After consideration of several models, the 
Shuttle traffic model of October 1974 was chosen as a baseline because it 
is in good agreement with a model generated directly from the SSPDA docu- 
ments. The 1974 traffic model stipulates that there are 226 Spacelab ope- 
rations out of a total of 572 Shuttle flights between 1980 and 1991, 
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The SSPDA documents were used to identify the experiments that are 
projected to be flown during each year between 1980 and 1991. An estimate 
of the number of flights per year that are required by each discipline was 
obtained by adding together the reentry weights for each of the experiments 
and then dividing the total reentry weight by the Shuttle experiment payload 
capability. The payload capability varied for each discipline as it was 
based on whether the discipline required the pallet-only, pallet-module or 
module-only mode. The numbers of flights that were required each year by 
the different disciplines on tne basis of the SSPDA documents are tabulated 
in Table 2-2 along with the same information from the 1974 flight traffic 
model. The di giplines have been grouped in a way that corresponds to the 
applicability of the results for the representative payloads that were 
selected and analyzed in Tasks 1 and 2 of this study (see Sections 2 and 3 
of Volume II). As might be expected in the early years, up through 1982, the 
SSPDA model indicated that substantially more flights were required than 
projected by the flight traffic model. However, after 1982, the agreement 
between the two models was good. In other words, in the early years the 
SSPDA document oversubscribes the number of flights whereas the 1974 flight 
traffic model indicates the actual maximum number of flights that are pos- 
sible. 

2.2.2 Payload Equipment Usage Schedule 

The NIM/CAMAC equipment requirements for each discipline were based 
on the representative payload equipment requirements that were compiled in 
Task 2 of this study. The equipment requirements for each year could be 
obtained on a qualitative basis by simply multiplying the number of units 
of CAMAC and NIM that were required by the representative payloads, by the 
number of flights per year projected by the baseline model. However, 
equipment requirements generated in this manner do not take into account 
the length of time the equipment has to be committed to a payload for a 
particular flight. If the payload equipment has to be committed only for 
a length of time that is less than the time between flights, the actual 
equipment requirements would be less than the simple estimate would indi- 
cate. Conversely, if the period of commitment is longer than the time 
between flights, the actual requirements would be increased. In order to 
take this factor into account, we will examine the payload development 
sequence before projecting the equipment requirements. 
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Table 2-2. Baseline Spacelab Flight Traffic Model (Flights/Year) 


Year: 

Astronomy 

SSPDA Model 
1974 Traffic Model 

High-Energy Astrophysics 

SSPDA Model 
1974 Traffic Model 

Solar Physics 

SSPDA Model 
1974 Traffic Model 

Atmospheric & Space Physics 

SSPDA Model 
1974 Traffic Model 

Earth Observation & 

Earth & Ocean Physics 

SSPDA Model 
1974 Traffic Model 

Life Sciences 

SSPDA Model 
1974 Traffic Model 

Space Processing & 

Space Technology 

SSPDA Model 
1974 Traffic Model 

Multidiscipl ine 

1974 Traffic Model 

Totals 


1980 1981 

1 % 2 
1 


1 % 1 % 
1 


1 1 
1 


1 

1 


3 3 


1 

1 


3 


6 % 

1 



SSPDA Model 10 16 

1974 Traffic Model 2 6 


1982 1983 1984 1985 


2 4 5% 6# 

2 3 2 3 


2 3 3 2 

12 12 


1 1 % 2 2 
12 2 2 


113 3 

12 2 2 


3 3 2% 2% 

2 2 3 2 


1111 
12 2 2 


7 . 6% 7 7 

3 4 7 7 


1 - - 1 


17 20 24 24 

12 17 19 21 


1986 

1987 

1988 

1989 

1990 

1991 

Totals 

Ik 

3% 

5 

3 

4 

2% 

47 

4 

4 

4 

4 

4 

4 

35 

2 

2% 

2 

2% 

2 

2 

26 

1 

2 

2 

1 

2 

2 

17 

1% 

2 

1% 

2 

1# 

2 

19 

2 

2 

2 

2 

2 

2 

20 

4 

3 

4 

3 

4 

3 

30 

2 

2 

2 

2 

2 

2 

20 

3 

3 

3 

3 

3 

3 

35 

3 

3 

4 

4 

5 

6 

34 

1 

1 

1% 

1% 

1% 

1^ 

13 

2 

2 

2 

2 

2 

2 

20 

7 

7 

7 

7 

7 

7 

79 

7 

8 

8 

8 

9 

10 

72 

- 

1 

- 

1 

1 

1 

8 

26 

22 

24 

22 

23 

21 

249 

21 

24 

24 

24 

27 

29 

226 



2. 2. 2.1 Spacelab Payload Development Sequence 

Because the latter phases of the sequence of operginons involved in 
a typical Spacelab flight are better defined, it is more convenient to dis- 
cuss the sequence in reverse order. After the flight is over, the post- 
flight operations will include a post-flight calibration of the instruments 
followed by removal of the payload from the Spacelab. Following payload 
disassembly, the NIM/CAMAC units would be tested, maintenance or recalibra- 
tion performed, as required, and they would be returned to a storage area, 
ready for their next assignment. We estimate that this sequence would re- 
quire about three months at the most. It is probably desirable to delay 
disassembly of the instruments until at least some data analysis has been 
performed. 

The flight itself lasts for seven to thirty days with the vast 
majority of flights being seven days. 

The pre-flight integration period is essentially composed of four 
phases. In the first phase (Level IV) each experiment or instrument is 
integrated with the racks and pallet segments that it requires and quali- 
fication tests performed. This phase should require about five months. 

In the next phase (Level III) the combination of instruments composing the 
payload are integrated and checked out. In Level II the payload integra- 
tion and checkout is extended to include the Spacelab flight subsystem sup- 
port elements. Finally, Level I is composed of integration and checkout 
of the Spacelab with the Shuttle Orbiter. Level III through I integration is 
currently estimated to take one month. The total integration time for 
Levels IV through I is therefore about six. months. 

The payload equipment to be used in the flight, including the NIM/ 
CAMAC equipment, will definitely have to be committed to the payload for 
the duration of the operations discussed up to this point. Thus the mini- 
mum period for which the flight NIM/CAMAC equipment must be coirmitted is 
about nine months. 

The payload development activities prior to Level IV integration will 
involve the design, development and testing of the individual instruments 
by the organizations responsible for the experiments or their contractors. 

We estimate that this activity will typically require at least nine months 
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and, frequently, several years may be needed. The existence of commercial 
units that are functionally identical to the NIM/CAMAC equipment to be" 
flown, allows an approach to the phases of instrument development sequence 
prior to Level IV integration that may be very cost-effective. Normally 
the approach used during instrument development and testing prior to inte- 
gration of the actual flight hardware involves a sequence of progressively 
more flight-like hardware such as breadboards, prototypes, etc. This de- 
velopment hardware is often nearly as expensive as the flight hardware. 
However, in the case of the NIM/CAMAC equipment, commercial units could be 
used if they are functional counterparts of the modified versions to be 
used in flight. We will consider the potential benefits of using commer- 
cial NIM/CAMAC equipment during instrument development in the next section. 

2.; 2. 2. 2 Commercial NIM/CAMAC Equipment Use for Instrument Development 

The use of commercial NIM/CAMAC units during instrument development 
and testing offers several advantages with respect to the use of equipment 
that has been modified and qualified for flight use. 

Cost - Since the instrument development and testing prior to Level IV inte- 
gration will require nine months or longer, the use of flight equipment 
during this phase of the instrument development would at least double the 
length of time that the flight units would have to be committed to a par- 
ticular payload. Consequently, the amount of flight equipment needed in a 
pool to support the Spacelab payloads would also be about doubled. The 
cost benefit to be derived from using commercial counterparts during in- 
strument development, and hence reducing the number of flight units neeoed 
by about one-half, can be assessed by recalling the modification costs dis- 
cussed in Section 1.4.2. Considering recurring unit costs only, NIM/CAMAC 
modules suitably modified for flight are estimated to be two to seven times 
as expensive as commercial units, depending on whether the modifications are 
minimum or more extensive (see Tables .1-7 and 1-8). Therefore, the total 
NIM/CAMAC equipment costs will be reduced from 25 to 43 percent compared 
to the approach in which flight units are used throughout the instrument 
development sequence. 

Maintainability - Since the instrument development activities prior to 
Level IV integration will be carried out by a variety of organizations at 
many different places, maintenance of the flight-qualified status of flight 
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equipment will pose a problem. If the flight modules were used for in- 
strument development and testing, they would require a flight status certi- 
fication after the return of the units from instrument testing, and prior 
to integration into the Spacelab. In contrast, if commercial units are 
used prior to Level IV integration, the flight modules would never be more 
widely dispersed than to the payload Level IV integration centers and cer- 
tification of their flight qualification could be much more easily con- 
trolled and maintained. Any instrument qualification testing at the de- 
veloper's facilities will now represent a qualification of the instrument 
sensor systems only. The full instrument qualification would occur during 
Level IV integration. 

Flexibil ity - During the instrument development phase it is unlikely that 
the modules that were originally designated for the instrument will be a 
perfect selection. Changes in this complement of modules will be more 
difficult if flight modules are used. The paperwork, delay in receiving 
the new units and recertification of the old units will take time and 
cause inconvenience to the development program. If commercial modules were 
used for the instrument development, changes could be made quickly as the 
restrictions on their use should be minimal due to their low cost and non- 
flight status. 

On the basis of these factors, the use of commercial units for in- 
strument development and testing is clearly preferred. The availability 
of this option arises naturally in the case of NIM/CAMAC equipment due to 
the existing wide range of commercial units. Consequently, in our further 
discussion of NIM/CAMAC implementation for Spacelab payloads, we will assume 
that commercial units are used prior to Level IV integration and that the 
flight units will be committed to a given payload for a particular flight 
for a period of nine months, 

2.2.3 NIM/CAMAC Equipment Usage Projections 

Having established the baseline position that the flight equipment 
will need to be committed for about nine months for any flight, we can 
return to estimating the NIM/CAMAC equipment usage across the baseline 
Spacelab flight traffic model. The nine-month commitment period means that 
the equipment usage can be projected on an annual basis, i.e., on the 
average, equipment for payloads flying during any given year will have to 
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be committed to those payloads only during the flight year. On the other 
hand, the schedule margin is close enough to preclude the use of the same 
equipment for more than one flight in a year. 

Hence, a reasonable estimate of the project annual NIM/CAMAC usage 
is given by simply multiplying the equipment requirements for the repre- 
sentative payloads by the number of flights per year given in Table 2-2 
for the corresponding discipline. The NIM and CAMAC equipment require- 
ments for the representative payloads were taken from Tables 3-53 and 3-54 
in Volume II of this report. In the disciplines where results from more 
than one representative payload were available (astronomy, high-energy 
astrophysics and space physics) an average of the requirements for the 
available payloads was used. For multidiscipline payloads an overall 
average of the requirements from the numerous disciplines was used. The 
resulting overall NIM and CAMAC equipment usage per year, obtained by 
summing over the various types of modules and the different disciplines, 
is presented in Table 2-3. 

Table 2-3. NIM/CAMAC Equipment Usage 


Equipment Usage (Units/Year) 


Year 

Flights 

CAMAC 

NIM 

Total 

1980 

2 

156 

210 

366 

1981 

6 

425 

141 

566 

1982 

12 

645 

324 

969 

1983 

17 

965 

478 

1443 

1984 

19 

990 

3 66 

1356 

1985 

21 

1066 

507 

1573 

1986 

21 

1096 

376 

1472 

1987 

24 

1156 

523 

1679 

1988 

24 

1218 

387 

1605 

1989 

24 

1071 

523 

1594 

1990 

27 

1255 

398 

1653 

1991 

29 

1292 

548 

1840 
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The annual usage rises up through 1983 as the number of flights per 
year increases to reach a level that remains fairly constant for the rest 
of the period covered by the baseline flight traffic model. The average 
annual usage from 1983 onward is about 1125 CAMAC units per year and 450 
NIM units per year. It should be emphasized that these numbers are the 
projected usage in contrast to the annual number of units that must be 
procured. The procurement requirements could only equal the usage rate in 
the unlikely event that each unit was only used once. Before turning to 
the question of procurement requirements, we will investigate the charac- 
teristics of an equipment pool that could support the projected usage. 

2.3 NIM/CAMAC EQUIPMENT POOL ANALYSIS 

In any pooled equipment approach the following functions would be the 
responsibility of the pool organization: 

e Procurement of equipment 
§ Distribution of equipment to users 
9 Maintenance and calibration of equipment 
t Provision of technical information and support to users. 

The main question that needs to be addressed is what type of equipment pool 
organization would perform these functions most efficiently and cost-effec- 
tively for the case of NIM/ CAMAC equipment to be used in Spacelab payloads. 

An obvious starting point is to draw upon the experience gained with 
NIM/ CAMAC equipment pool operations at ground-based laboratories. However, 
there are significant differences between these examples and the situation 
that will apply for Spacelab payloads. In the typical case of the larger 
hign-energy physics laboratories such as the National Accelerator Labora- 
tory, Lawrence Berkeley Laboratory, Stanford Linear Accelerator Center, 
etc,, the equipment users are located at the facility during the perfor- 
mance of their experiments. In this relatively simple situation where all 
of the demand for equipment comes from local sources, one central pool at 
each facility is clearly the answer. In the case of Spacelab payload ope- 
rations, during experiment development the experimenters will be widely 
scattered throughout the U.S. and conceivably the world. As payload inte- 
gration proceeds the activities will become progressively more centralized. 
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culminating in final integration at the Shuttle flight center (either 
Kennedy Space Center or Vandenberg Air Force Base). Therefore, a different 
pool organization may be more efficient in this case. 

2.3.1 Alternative Pool Concepts 

In principle, a wide spectrum of equipment pool concepts ranging from 
one centralized pool supporting all Spacelab users to a number of pools 
that each support a particular segment of the user community such as ex- 
perimenters in one discipline or one geographical area could be considered. 
However, a centralized pool will always be more cost-effective in direct 
terms because of the following factors: 

9 Less duplication of effort and more efficient utilization 
of pool manpower 

9 More uniform demand for services due to averaging over a 
larger community of users 

• Higher level of consolidation in equipment procurement. 

Therefore, we have taken the approach of starting from the concept of one 
centralized pool and attempting to identify what requirements, if any, 
could justify the adoption of a more decentralized pool organization. 

The disadvantages that normally arise from overcentralization mainly 
involve a loss of flexibility to deal with special user requests, inability 
to respond to demands for rapid service from a widely dispersed user com- 
munity and intolerance to ill-defined or frequently changed user require- 
ments. If any of these circumstances apply during the development and in- 
tegration of Spacelab payloads, the resulting user inconvenience and de- 
lays could translate into cost increases that offset the cost advantages 
of a centralized equipment pool. 

In considering the case of NIM/CAMAC equipment for Spacelab payloads, 
we could identify only a limited number of potentially significant pro- 
blems that might occur with a centralized pool organization. 

In terms of the functions of the pool organization, the procurement 
of flight NIM/CAMAC equipment and the provision of technical information 
and support would definitely be more efficiently handled by a centralized 
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organization. In addition, if the use of flight NIM/CAMAC equipment is 
limited to Level IV and higher integration phases as discussed in the pre- 
ceding section, no problems were foreseen with maintenance and calibration 
of the flight equipment by a centralized organization. 

Problems could arise with a centralized pool organization in the 
area of equipment distribution if a requirement for rapid service to 
widely dispersed users occurred. However, during the phases of the Space- 
lab payload operations sequence when rapid response is critical, i.e., 
during Level II, II and I integration, the users will all be located at one 
of the two flight centers. Thus, if the equipment pools are also located 
at the flight centers, delays would be held to a minimum. 

During instrument development and testing prior to Level IV integration 
the users are widely dispersed and user requirements may also be ill-defined 
and frequently changed. However, in this case only commercial units 
would be involved. The distribution of commercial units could be handled 
by the central pool without restrictive controls because of their rela- 
tively low cost and the absence of any requirements to maintain a flight- 
qualified status. The instrument developers could also have the option 
of going directly to commercial suppliers if the central pool was unable 
to provide adequate service. 

No meaningful comparison can be made at this time between the total 
inventory of equipment that must be maintained to support payload usage 
with alternative pool concepts. More data is needed than is available 
with the limited sample of representative payloads on the variation of 
equipment requirements from payload to payload in the segments of the 
user community served by individual pools in a multiple pool approach. 

In general , a centralized pool would be expected to require less equipment 
because of the averaging over a larger number of users. A rough indica- 
tion of the differences that can be anticipated is provided by a compa- 
rison between the total equipment procurement requirements for a centra- 
lized pool to be calculated in Section 2.4 and for a dedicated equipment 
approach to be calculated in Section Z.5. As we will see, the dedicated 
approach, which to a certain extent represents a maximally decentralized 
approach, requires about 33 percent more equipment over the first six 
years of Space lab operations. 


65 



In summary, we do not foresee any factors in the Space! ab user re- 
quirements for NIM/CAMAC equipment that could offset the overall cost 
advantages of a centralized pool approach if commercial equipment is used 
during the instrument development phase and provision is made for rapid 
response service at Vandenberg when Spacelab payloads start operating from 
there. 

2.3.2 Recommended Pool Concept 

The recommended pool concept is shown di agrammatical ly in Figure 2-1. 
The organization includes a control center for pool operations and equip- 
ment pool and distribution centers at the Shuttle flight centers (KSC and 
VAFB). The control center is a permanent element that performs the func- 
tions of overall pool management, technical information support for users 
and equipment procurement. The control center would most likely be located 



Figure 2-1. Recommended Organization of the 
NIM/CAMAC Equipment Pool 
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at KSC but this choice is not critical. The actual number of distribution 
centers in operation at any time will depend on the demand. For example, 
in the initial years of Spacelab operations only the distribution center 
at KSC will be needed since Shuttle operations will not start at Vandenberg 
until 1983. Additional distribution centers can be established if the 
sufficient demand exists. 

The estimated manpower required to operate this pool and approximate 
annual labor costs at current rates are given in Table 2-4 for both the 
initial phase of operation in 1980 and for 1984 when equipment usage has 
reached a stable level and the pool is at its full size. The operational 
costs of the pool have to be considered when estimating the total cost of 
implementing a shared equipment approach for NIM/CAMAC equipment. How- 
ever, most of the functions provided by the pool will have to be provided 
by somebody in any approach, so only a small fraction of the pool opera- 
tional costs can be uniquely associated with the use of an equipment pool. 

Table 2-4. Manpower Requirements and Costs for . 

Operation of the Recommended Pool Concept 

Number of Persons and Cost/Year ($000) 


Location 

Labor Category 


1980 


1984 




Manager 

1 

0 

65 = 65 

1 

0 

65 

= 

65 

Control 

Procurement Officer 

1 

0 

50 = 50 

1 

0 

50 

= 

50 

Center 

Information Officer 

2 

0 

50 = 100 

2 

0 

50 

= 

100 


Clerical & Support 

2 

0 

25 = 50 

3 

0 

25 

= 

75 

KSC 

Pool 

Supervisor 

1 

0 

50 = 50 

1 

0 

50 

= 

50 

Technician 

1 

0 

40 = 40 

3 

0 

40 

= 

120 

Clerical & Support 

1 

0 

30 = 30 

3 

0 

30 


90 

VAFR 

Supervi sor 



- 

1 

0 

50 

= 

50 

V r\l U 

Pool 

Technician 




1 

0 

40 

= 

40 

Clerical & Support 




1 

0 

30 

= 

30 


Total Cost $385K $670K 
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2.4 EQUIPMENT COSTS AND POOL MANAGEMENT PLAN 

Before NIM/CAMAC equipment costs can be estimated for the pooled-equip- 
ment approach, the time-phased procurement requirements to support the 
estimated yearly usage shown in Table 2-3 must be determined. 

2.4.1 Pool Equipment Procurement Requirements 

The minimum pool equipment procurement requirements were calculated 
directly from the detailed equipment usage requirements as follows: starting 
with the tabulation of the numbers of each type of NIM and CAMAC equipment 
item used in each year by the payloads in each discipline (i.e., the number 
of flights in each discipline for each year times the appropriate represen- 
tative payload equipment requirements) , the annual usage requirements for 
each NIM and CAMAC equipment item were determined by summing over all of 
the disciplines. The annual procurement requirement for each equipment 
item is equal to the number of units that must be added to the pool each 
year to maintain an inventory that is at least equal to the number of units 
to be used in the year. The results of this calculation for the first four 
years of Spacelab operations (the period of primary pool buildup) are tab- 
ulated in Table 2-5. These minimum procurement requirements were next ad- 
justed upwards to take into account the needs for spare units, and 
replacement units. 

2. 4. 1.1 Space Unit Requirements 

We assumed that a number of spare units approximately equal to twenty 
percent of the number of units in the pool should be available to cover 
contingencies and variations in user requirements. However, because of the 
small size of the pool in the early years, the procurement profile was 
adjusted to provide close to forty percent spares in the first year and a 
gradual decline in the number of spare units to an average of about fifteen 
percent when the pool has reached fullsize. This approach has the added 
advantage of smoothing out the fluctuations in the yearly procurement 
profile. 

2 . 4 . 1 . 2 Replacement Unit Requirements 

Since the equipment has a finite life expectancy, new units will have 
to be procured as old units are removed from inventory. The effective life 
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Table 2-5. Equipment Pool Procurement Requirements for 1980-1983 
(no spares or replacements included) 


CAMAC 


Year 


Year 


CAMAC Equipment Item 

Code 



82 


NIM Equipment Item 

80_ 

il 

82 


Scalers 

111 

23 

0 

13 

23 

Shaping Amplifiers 

37 

7 

25 

35 

Preset Scalers 

113 

1 

4 

3 

3 

Fast Amplifiers 

2 

0 

0 

0 

Position Encoders 

117 

6 

8 

8 

12 

Delay Amplifiers 

3 

0 

0 

1 

Input Gates 

121 

6 

15 

15 

11 

Sum/ Invert Amplifiers 

32 

0 

1 

19 

Input Registers 

122 

1 

6 

8 

0 

Linear Gates 

1 

0 

16 

0 

Logic Units 

123 

4 

0 

2 

2 

Fast Linear Fan-Ins 

9 

0 

0 

3 

Interrupt Registers 

127 

2 

4 

3 

5 

Fast Linear Fan-Outs 

3 

0 

0 

1 

Clocks & Pulse Generators 

131 

4 

6 

2 

12 

Fast Integral Discriminators 

21 

0 

0 

11 

Output Registers 

132 

5 

12 

14 

16 

Slow Integral Discriminators 

6 

9 

3 

12 

Output Drivers 

133 

11 

23 

30 

20 

Single Channel Analyzers 

1 

3 

7 

6 

Stepping Motor Controllers 

145 

16 

42 

26 

44 

Zero Crossing Discriminators 

5 

0 

0 

3 

Analog to Digital Converters 






Constant Fraction Discriminators 

8 

0 

0 

4 

High Resolution - Fast 

161 

18 

56 

12 

48 

Coincidence Units 

15 

0 

0 

7 

Multichannel - Slow 

161 

15 

40 

25 

37 

Pulse Height Analyzer 

1 

1 

0 

0 

Time Digitizers 

161 

16 

0 

0 

12 

High Voltage Power Supplies 

38 

0 

34 

38 

Digital to Analog Converters 

162 

4 

15 

6 

14 

NIM Bins W/Power Supply 

21 

0 

11 

6 

Multiplexers 

164 

4 

23 

0 

9 

Special Modules 





Branch Drivers 

211 

2 

5 

4 

5 

Sequence Discriminator 

5 

0 

4 

7 

Crate Controllers 

231 

9 

19 

14 

21 

Wave Analyzer 

1 

3 

0 

2 

Crates W/Power Supply 

411 

9 

19 

14 

21 

Differential Amplifier 

1 

0 

0 

0 

CAMAC Totals 

156 

297 

199 

315 

NIM Totals 

210 

23 

101 

155 



expectancy of NIM/CAMAC equipment being used in Spacelab payloads is a 
difficult quantity to estimate. The possible factors to be considered in 
arriving at an estimate are: 

t Failure rates 

• Maintenance costs vs. replacement costs 

• Obsolescence 

Conventional failure rates for NIM/CAMAC equipment can be estimated 
from failure rate data on the types of electronic components used in the 
circuits. Even for industrial -grade parts, the corresponding life expec- 
tancies are greater than ten years. In addition, the units can be repa-ired 
so the calculated failure rates don't represent the actual situation. The 
real failures will probably occur because of overstressed components, mar- 
ginal design, or misuse. Recalling the discussion of the modifications for 
Spacelab use in Section 1.4, the first two causes are much more likely to 
occur in equipment with minimum modifications since the commercial circuit 
design and part selection are used without modification. For this type of 
failure, repair by simply replacing the failed part does not cure the prob- 
lem. In any case, the life expectancy due to actual failures will probably 
be on the order of five to ten years for minimum-modified equipment and 
greater than ten years for more extensively modified equipment. 

Another limit on the effective life of the equipment is the point at 
which it becomes more expensive to continue maintaining a unit than to re- 
place it. We estimate the typical maintenance cycle for a unit will cost 
about $200. Hence, at a rate of one cycle per year, even the minimally 
modified units could be maintained for six years before the maintenance 
costs equal the original cost. 

The factor that we believe will really control the effective useful 
life of the equipment is obsolescence. If new units with improved perfor- 
mance are available, users will tend to quit using the older models. The 
situation is actually a tradeoff between the increased costs of a higher 
replacement rate and the users' preference for the latest model. The most 
cost-effective approach will be for the pool to resist the users' tendency 
to switch to a new model unless it is truly required. Experience with NIM/ 
GAMAC equipment pools indicates that the useful life of a unit in these 
circumstances is about seven years, on the average. We, therefore, have 
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used this number for the life expectancy of a more extensively modified 
unit. In view of the lower unit cost and higher expected failure rate of 
minimally modified equipment, we have assumed four years to be its average 
life expectancy. 

The average life expectancies were factored into the equipment procure- 
ment requirements by using an annual replacement rate for pool equipment 
that results in total replacement of the inventory in a period equal to the 
average life expectancy. 

2 . 4 . 1 . 3 Refined Pool Equipment Procurement Requirements 

The annual NIM/CAMAC equipment procurement requirements for the recom- 
mended pool concept, which were calculated as described in the preceding 
sections, are given in Table 2-6. 

Table 2-6. NIM/CAMAC Equipment Pool Procurement Requirements 


NIM/CAMAC Units Procured per Year 


Year 

Pool Size 

Minimum 

Modification 

More Extensive 
Modifi cation 

1980 

500 

500 

500 

1981 

785 

410 

356 

1982 

1200 

611 

527 

1983 

1720 

820 

691 

1984 

1720 

430 

246 

1985 

1800 

510 

326 

1986 

1800 

’ 450 

257 

1987 

1850 

500 

307 

1988 

1850 

463 

264 

1989 

1850 

463 

264 

1990 

1850 

463 

264 

1991 

1850 

463 

264 


2.4.2 Cost Estimate for Pool Equipment 


NIM/CAMAC pool equipment costs were estimated on the basis of both 
minimally modified and more extensively modified flight units. The non-re- 
curring design, development and test costs as well as the recurring unit 
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costs were given in Tables 1-7 and 1-8. For our purposes here, these esti- 
mates were used to generate the average module cost including non-recurring 
development as a function of the number of units procured. This relation- 
ship is plotted in Figure 2-2 for both modification cases. The cost esti- 
mates for the NIM/CAMAC pool equipment were then generated using annual 
procurement requirements for each type of NIM and CAMAC equipment item (the 
equivalent of Table 2-5 after spare and replacement units were added) and 
the curves in Figure 2-2. The results are given in Table 2-7. Two sig- 
nificant points should be noted. First, the relatively low cost of the 
pool equipment in general, especially after the initial buildup period. 
Second, although the more extensively modified units are initially four to 
five times as expensive as the minimally modified units, the difference over 
the entire 1980-1991 period is only a factor of two due to the large quanti- 
ty of units procured. 

These cost estimates cover only the NIM/CAMAC flight equipment. An 
equal quantity of commercial units will need to be procured for instrument 
development and testing. The total cost of commercial units over the twelve- 
year period is about $3.6 million or an average of $0.3 million/year. Al- 
though significant, this cost is well below the flight unit costs. Also 
the pool operational costs given in Table 2-4 should be included for a more 
complete NIM/CAMAC pool cost estimate. The cumulative pool operational cost 
over the twelve-year period is $8.0 million. Including the commercial units 
and pool operational costs, the total pool cumulative costs for 1980-1991 
are $20.8 million and $30.6 million, respectively, for the minimum and more 
extensive modification cases. Hence, the cost difference between the two 
levels of modification is even less significant when the fixed overhead of 
the equipment pool is taken into account. 
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Figure 2-2. Average Module Costs Including Nonrecurring Development 
Versus Numbers of Units Produced 

Table 2-7. Estimated Costs for NIM/CAMAC Pool Equipment 

Equipment Costs (M$) 



Minimum 

Modification 

More Extensive 

Modifi cation 

Year 

Cost/Year 

Cumulative 

Cost/Year 

Cumul ati ve 

1980 

1.15 

1.15 

4.25 

4.25 

1981 

0.66 

1.81 

1.71 

5.96 

1982 

0.92 

2.73 

2.30 

8.26 

1983 

1.23 

3.96 

2.59 

10.85 

1984 

0.60 

4.56 

0.92 

11.77 

1985 

0.71 

5.27 

1 .22 

12.99 

1986 

0.63 

5.90 

0.96 

13.95 

1987 

0.70 

6.60 

1.15 

15.10 

1988 

0.65 

7.25 

0.91 

16.01 

1989 

0.65 

7.90 

0.99 

17.00 

1990 

0.65 

8.55 

0.99 

17.99 

1991 

0.65 

9.20 

0.99 

18.98 
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2.5 DEDICATED EQUIPMENT APPROACHES 

Our primary objective in considering implementation approaches in 
which the NIM/CAMAC equipment used by each payload was assumed to be dedi- 
cated to that payload and not available to other users was to provide a 
cost comparison with the pool approach. In addition to providing the basis 
for the determination of the cost impact of equipment sharing by users, con- 
sideration of a dedicated equipment approach also allowed us to make a cost 
comparison between the use of standard NIM/CAMAC equipment and the use of 
functionally equivalent, custom-built equipment. This type of equipment 
would by definition be dedicated to the payload for which it was developed. 

2.5.1 Equipment Requirements for Dedicated Approaches 

It is important to realize that even in a dedicated equipment approach, 
the equipment will in general be used a number of times if the payload to 
which it is dedicated is reflown. The relative cost of dedicated equipment 
usage compared to the adoption of an equipment pool thus depends critical- 
ly on the number of payload reflights. This can be seen by considering the 
situation in which a payload using dedicated equipment is flown every year. 
In this case, it makes no difference if the equipment is dedicated to the 
payload or is part of an equipment pool. Therefore, it is necessary to 
establish the actual new payloads in our baseline Spacelab flight traffic 
model as opposed to reflights of existing payloads. 

2. 5. 1.1 Baseline Model for New Payloads 

The number of new payloads the baseline Spacelab traffic model was 
estimated on the basis of the misiion frequency information contained in the 
1974 version of the SSPDA documents. The method used was similar to that 
previously described in Section 2.2.1. In this case, however, an instru- 
ment or payload listed in the SSPDA tabulation was only included in the 
calculation of the number of full payloads in each discipline for the first 
year in which it appeared. In other words, reflights were not counted. 

This information was converted to the number of new payloads in the base- 
line model by assuming that the fraction of the total number of flights 
per year in each discipline which were new payloads was the same as that 
found in the SSPDA tabulations. 
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The result of this process was that only 23 out of a total of 77 
flights in the first six years of the baseline model (1980-1985) involved 
new payloads and essentially all flights after 1985 were reflights. Nat- 
urally, this simply reflects the understandable fact that there is a very 
large number of reflights projected in the SSPDA tabulation and all of the 
payloads identified are assumed to fly for the first time before 1985. This 
is undoubtedly not a realistic representation of Spacelab payload operations, 
but no better information is available on which to base the estimate. Since 
the number of new payloads estimated in this way becomes increasingly un- 
realistic in the later years of the payload model, we only carried the exer- 
cise on dedicated equipment through 1985. 

2. 5. 1.2 NIM/CAMAC Equipment Procurement Requirements for a Dedicated 
Approach 

Given the number of new payloads in the baseline model, it is a straight- 
forward process to estimate the amount of equipment that must be procured 
each year in a manner that is analogous to that used for the pooled equip- 
ment case. The same assumptions were used to adjust the initial estimated 
requirements to take into account the finite life expectancy of the equip- 
ment and the need for spare units to cover contingencies (i.e., replacement 
cycles of four and seven years, respectively , for minimum and more extensive 
modifications; and 20 percent spare units). The resulting total numbers 
of units that must be procured each year are given in Table 2-8. 

Table 2-8. Dedicated NIM/CAMAC Equipment 
Procurement Requirements 

NIM/CAMAC Units Procured per Year 


Year 

Baseline Traffic Model 
Flights New Payloads 

Minimum 

Modification 

More Extensive 
Modif i cati on 

1980 

2 2 

383 

383 

1981 

6 6 

656 

615 

1982 

12 8 

1064 

963 

1983 

17 4 

888 

698 

1984 

19 1 1/2 

645 

408 

1985 

21 1 1/2 

705 

458 
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The total procurement requirement over the 1980-1985 time period is 
only about 33 percent greater than in the pool approach for both minimum and 
more extensive modifications. The advantages of the pool approach would 
probably be more significant in the following years. Whereas the pool has 
attained full size by 1985 and only requires a reasonable amount of replace- 
ment to be maintained, new requirements will continue to arise in the dedi- 
cated equipment case. A reasonable approximation of the 1986-1991 time 
period for the dedicated case would probably be. given by assuming a repeat 
of the 1980-1985 requirements. If so, the dedicated equipment approach 
would require procurement of about twice as many modules as the pool 
approach. 

2.5.2 Estimated Costs for Dedicated Approaches 

2. 5. 2.1 Dedicated NIM/CAMAC Equipment Costs 

The cost estimates for the dedicated NIM/CAMAC equipment were gene- 
rated in the same way as for the pool equipment. In particular, it was 
assumed that although the equipment would be dedicated to individual pay- 
loads, the procurement requirements for the various payloads would be 
consolidated. Even if this assumption was not literally valid, the unit 
prices of the equipment would certainly reflect the overall level of pro- 
curement. The results are given in Table 2-9. 

2. 5. 2. 2 Custom-Built Equivalent Equipment Costs 

It is also a straightforward process, given the number of new payloads 
in each discipline, to estimate the comparable cost of implementing the 
payloads in the way it is conventionally done at present. For this case, 
equipment that is functionally equivalent to the NIM/CAMAC equipment re- 
quired by the payload would be developed and manufactured specially for 
each payload. It was assumed that advantage would be taken of the com- 
monality of requirements that existed within each payload. Thus, a unit 
cost versus number of units curve, analogous to those in Figure 2-2, but 
based on Table 1-9, was used to estimate the cost of the equipment re- 
quired for each representative payload plus 20 percent spare units. No 
equipment replacement was included in the estimated cost. The costs of 
the representati ve payload in each discipline were simply multiplied by the 
numbers of new payloads in the disciplines to arrive at the programnatic 
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Table 2-9. Equipment Costs for Dedicated Approaches 


Equipment Costs (M$) 


Year 

Minimum 

Cost/Year 

Modification 

Cumulative 

More Extensive 
Cost/Year 

Modification 

Cumulative 

Custom- 

Cost/Year 

■Built 

Cumulative 

1980 

0.88 

0.88 

3.26 

3.26 

8.66 

8.66 

1981 

0.98 

1.86 

2.74 

6.00 

16.60 

25.26 

1982 

1.49 

3.35 

3.35 

9.35 

24.40 

49.66 

1983 

1 .24 

4.59 

2.15 

11.50 

12.65 

62.31 

1984 

0.90 

5.49 

1 .26 

12.76 

3.80 

66.11 

1985 

0.99 

6.48 

1 .41 

14.17 

4.56 

70.67 



cost estimates. The results are given in Table 2-9 along with those for 
modified NIM/CAMAC equipment. 

2.5.3 Comparison of Costs for the Alternative Approaches 

Because of the low number of new payloads in the baseline payload model 
used and the assumption of consolidated procurement, the estimated cumula- 
tive equipment costs for a dedicated implementation approach are only 
slightly greater than the comparable pool equipment costs ($6.5 million 
versus $5.3 million and $14.2 million versus $13.0 million, respectively, 
for the minimum and more extensive modification cases). 

Although the frequency of reflights has probably been overestimated, 
these results do indicate that the cost saving to be realized by the es- 
tablishment of an equipment pool will probably not be great in the early 
years of Spacelab payload operations. As already discussed, the cost bene- 
fits of a pooled-equipment approach will probably be more significant in 
the later years of payload operations. This suggests that the most reason- 
able approach would be to start out by setting up the amount of central 
control needed to establish the standards to which equipment is to be built 
and to coordinate the equipment requirements and procurements of the various 
payloads, but to not set up an actual equipment pool. As the situation 
evolves, actual equipment pool operations can be initiated when warranted 
by the level of equipment usage and degree of user acceptance. 

In contrast to the relative costs of pooled and dedicated approaches, 
the cost of comparable custom-built equipment is seen to be five to ten 
times greater than the implementations using standard NIM/CAMAC equipment. 
While this is due in part to the higher nonrecurring development and re- 
curring unit costs used for this equipment, the largest portion of this 
cost increase is due to the assumed absence of standardization beyond the 
payload level. In other words, the amortization of nonrecurring development 
costs is greatly reduced in this case. 

In order to illustrate this point, our analysis of alternative imple- 
mentation approaches can be generalized to consider all of the available 
options. The generalization can be viewed as an investigation of the equip- 
ment costs as a function of two independent parameters: the level of equip- 

ment modification and the degree of standardization in the implementation 
approach. 
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So far as the level of modification is concerned, we already have the 
necessary information for three levels, if what we have been using to this 
point as the approach for custom-built equipment (see Section 1.4. 2. 3) is 
interpreted as the maximum level of modification. The estimated costs 
(Table 1-9) do not depend on whether the equipment is standard or custom- 
built. 

Two key questions are involved in the alternative implementation ap- 
proaches; is the equipment shared by users or dedicated to individual 
payloads and is the equipment procured in common for all payloads or pro- 
cured separately for each payload? Out of the four possible combinations, 
the case of separate procurement but shared usage is not germane. Thus 
three alternatives are available. 

The comparable equipment costs for all nine possible options can 
easily be estimated using the methods and assumptions already described. 

In fact, five options have already been estimated. The estimated 1980-85 
cumulative costs for the complete matrix of possible options are given in 
Table 2-10. The results illustrate the fact that the sharing of nonrecur- 
ring development costs made possible by standardization is more important 
than shared usage of the equipment. As would be expected, this conclusion 
becomes stronger as the level of modification, and hence the nonrecurring 
development cost, increases. 

Table 2-10. Comparative Costs of Alternative Equipment Implementations 


Equipment 

Implementation 

Approach 

Pooled Standard Equipment 

• shared usage 
§ common procurement 
for all payloads 


Cumulative Equipment Costs for 1980-1905 (M$) 

Degree of Modification 
Mi nimum More Extensive Maximum 

5.3 13.0 22.3 


Dedicated Standard Equipment 6.5 14.2 26.1 

d dedicated usage 
• common procurement 
for all payloads 

Dedicated Custom Equipment 8.9 35.6 70.7 


t dedicated usage 
0 separate procurement 
for each payload 
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3. IMPLEMENTATION AND IMPACT OF CAMAC ON 
SPACELAB EXPERIMENT SOFTWARE (TASK 4B) 


3.1 INTRODUCTION 

In order to properly assess the cost effectiveness of adopting the 
NIM/CAMAC standards for Shuttle experiment data acquisition and control sys- 
tems, one cannot ignore the associated software development and implementa- 
tion costs. No cost savings can accrue to NASA if, in the effort to minimize 
expenditures, an economical hardware standard is adopted that requires ex- 
tensive additional software expenditures cancelling or exceeding the savings 
originally derived from the hardware standards. If a CAMAC hardware system 
is implemented for experiment control and data management, significant por- 
tions of the software will directly support the hardware functions and 
since these hardware functions will be common to many experiments there will 
also be considerable commonality in the supporting software. Therefore, 
those portions of the experiment software systems that directly support the 
CAMAC hardware functions need be written only once and can be supplied to 
the individual experiments in parallel with the pooled hardware. 

3.1.1 Scope of the Software Task 

The objective of this task is to investigate the impact and implementa- 
tion of such a software system. The effort was divided into four subtasks. 

Task 4B.1 Survey and summarize representative existing CAMAC 
software systems. 

Task 4B.2 Survey and summarize current information on the 
Spacelab software system. 

Task 4B.3 Investigate a system of pooled CAMAC support software. 

Task 4B.4 Analyze the major software requirements for two 
representative payloads. 

Four existing CAMAC software systems were selected from the available 
examples. These four systems provide a reasonable sample of the range of 
CAMAC software system concepts used in different applications that each 
have at least some key requirements that will be encountered in implement- 
ing Spacelab payload software. All of the available documentation on these 
software systems was obtained and a summary of the relevant features of each 
was prepared with an emphasis on their approach to user application program 
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implementation. 

Next, the available documentation describing the Spacelab software 
environment for payloads was reviewed and summarized with emphasis on 
those features most relevant to payloads using CAMAC hardware. 

The results obtained in the surveys of existing CAMAC software sys- 
tems and the Spacelab software system were applied to investigate software 
implementation for CAMAC systems used in Spacelab. Functional criteria 
were identified to distinguish two general categories of CAMAC usage in 
Spacelab payloads and recommended approaches to handle each were formu- 
lated. The types of standard CAMAC software to be provided for users 
were defined and the impact of the use of CAMAC hardware on experiment 
software development costs was assessed. 

Finally, the major software requirements were analyzed for two of 
the representative payloads selected and analyzed in Tasks 1 and 2. Top 
level software system diagrams were developed to provide specific examples 
of the recommended approaches to CAMAC software implementation and the 
standard CAMAC interface subroutines required by each payload were identi- 
fied. 

3.1.2 General Experiment Software System Requirements 

The following major elements are required in a software system to be 
used for experiment control and data acquisition: 

® The operating system for the processor which handles executive 
services such as task scheduling, system resource allocation 
and system initialization and loading. 

9 Input/output drivers which handle data transfers to and from 
peripheral hardware. 

9 A utility library which provides commonly-used computation and 
analysis routines, display control routines etc. 

@ The application program which defines the sequence of operations 
required by the experiment. 

@ Software development aids such as high-order language compilers, 
assemblers, editors and simulators. 

The operating system of the software is unique to the computer central 
processing unit and is usually supplied by the computer manufacturer. The 
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operating system is a collection of programs such as the monitor program, 
executive program, system loader, system preparation routine; i.e., those 
programs required to allow the hardware to perform the desired functions of 
a computer. The operating system is written in efficient machine language. 

The input/output drivers handle communications between the central 
processing unit and peripheral hardware such as tape recorders, printers, 
disc memories, keyboard units, display units, and of particular interest 
here, experiment data acquisition and control hardware such as CAMAC, 

Most software systems include a library of utility routines that per- 
form commonly used functions such as special mathematical functions, statis- 
tical analyses, matrix manipulation, display control, etc. These utility 
routines are usually designed to be called from a high-order language pro- 
gram and facilitate the user's development of his application program. The 
utility routines are frequently written in assembly language to maximize 
operating efficiency. 

The application program is the software which has been created to pro- 
vide the events and data acquisition desired by the experimenter. This 
must be accomplished within the constraints of the operating system and the 
hardware system. This software can be in a high-level language to minimize 
programmer time or in assembly language to minimize core requirement and/or 
minimize machine time. 

The software development aids are all intended to minimize the user's 
effort required to generate, integrate, and check out his software. 

All of these elements except the applications program, which must be 
developed for each specific experiment, are usually provided to the user by 
the host software system and certainly should be provided for Spacelab users 
The magnitude of the experiment software effort depends Critically on the 
availability and convenience of use of these software system elements. 
Ideally, the experiment software development should only involve developing 
the applications program. 

3.1.3 Impact of CAMAC on Software Requirements 

The use of CAMAC hardware really only directly impacts the software 
system by allowing the use of standard input/output drivers for the CAMAC 
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hardware. The drivers should ideally make the details of the host software 
system as transparent as possible to the user. 

The CAMAC driver routine loads all the CAMAC commands, which are gen- 
eral ly provided by the application program, into the registers of the CAMAC 
branch driver (serial or parallel) or of the crate controller if a stand- 
alone type U crate controller. Since bit manipulation and transfers tc 
specific core addresses are often required, this must be accompl ished by a 
low-level language. In addition, as the low-level language depends on the 
computer and the registers can differ among branch drivers, this portion of 
the software is usually unique for each computer and each manufacturer's 
branch driver. While used often, this routine really only transfers four 
standard CAMAC pieces of information; i .e., 1) CAMAC function, 2) CAMAC 
address, 3) CAMAC data (when required) , and 4) CAMAC status. 

The actual manipulation of CAMAC commands and data is accomplished 
differently by the various users as will be pointed out in the discussions 
of the four CAMAC applications which are reviewed in the following sections. 
Most CAMAC software implementations aimed at simplifying the creation of the 
application program are based upon a subroutine for each CAMAC module to 
construct the desired call to the CAMAC driver. 

In cons i deri ng the imp! emen tati on of the Spacel ab software system , i t 
1s evident that compared to completely unique systems for each experiment 
there are many potential advantages to working with a subsystein of CAMAC 
software interfacing with CAMAC hardware in the experiment control and data 
management system. 

A major advantage of a CAMAC system is that the hardware/scftware rn ■ 
terface is firmly established. This means that the details of 'i^he interface 
do not have to be readdressed each time the software for a new experiment 
is being generated. The experiment unique software has only to Intelli- 
gently call the module level subroutines in order to communicate with the 
hardware. This results in a significant reduction in the amount of soft- 
ware that has to be written for each individual experiment. 

Another advantage is that since the CAMAC system software need be 
written only once to handle all experiment.s, it can be written in the 
assembler language of the host system. This minimizes the core space 


83 



required by the subroutines and maximizes their efficiency. It also means 
that the CAMAC software can be documented more thoroughly as it is generated 
making it more accessible to new users and review personnel. 

A final advantage of the CAMAC software system is the ease with which 
it is understood. Since it is structured to directly support the pool of 
hardware, there is never any indecision about the software requirements of 
a given hardware system. As soon as the hardware modules for an experiment 
are chosen, the software support functions required by these modules are 
known. The process of reviewing and approving an experiment software system 
for flight is greatly simplified since large sections of that software will 
be from the CAMAC software pool . 
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3.2 EXISTING SOFTWARE SYSTEMS 

Four examples of software implementation for CAMAC systems were selected 
from the large number of available examples. As in the case of CAMAC hard- 
ware (see Section 3.1.2 and Appendix I, Volume II), a CAMAC Product Guide 
for software is published in each issue of the CAMAC Bulletin. The edition 
from Issue No. 14 (December 1975) is reproduced in Appendix I of this volume 
to illustrate the amount and type of CAMAC software currently available. 

3.2.1 Hot Fuel Examination Facility 

3. 2. 1.1 General Description 

The Data Acquisition and Process Control System at the Hot Fuel Examin- 
ation Facility is primarily a dedicated system for computerized automatic 
control and data acquisition of fuel element examination via two CAMAC par- 
allel highways. The software system is relatively static because of its 
dedicated function. The softv;are system, operating on a Datacraft 6024/3 
central processor, makes extensive use of assembly language to achieve high 
operating efficiency. 

Hot-cell examinations such as gamma scanning produce vast amounts of 
data, and only so much data can be taken during an eight-hour shift. Auto - 
mation of the examination device has improved the situation by making it 
possible to operate the device twenty-four hours a day without operator 
attention and by improving the efficiency of the machine through automation. 

The Data Acquisition and Process Control System uses a Datacraft 6024/3 
central processing unit. This is a medium-sized computer with a word length 
of 24 bits, a cycle time of 1 microsecond, and 32‘-k-word magnetic core mem- 
ory. Peripheral equipment consists of a 28-megabyte moving head disc, two 
9-track magnetic tape units, four 7-track magnetic tape units, card reader, 
line printer, teletype, engineering display terminal, three remote terminals, 
and the two CAMAC parallel highway systems. Figure 3-1 is a schematic of 
the system. 

3 . 2 . 1 . 2 Software System Description 

Operation System - The Disc Monitoring System (DMS-III) operating system 
provides foreground multiprogramming concurrently with background batch pro- 
cessing. The real-time, application programs are run in foreground and 
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receive highest priority. Background programs, which carry out the data 
reduction, are serviced as time permits. Each time a significant event 
occursi e.g., an operation that causes an active program to become idle, 
the program list is examined from top to bottom to find a program to run 3 
the dispatcher enters ^n idle loop to await another significant event; i,e., 
an operation that causes a suspended program to become active. 

For high-speed devices such as magnetic tape or disc units, the trans- 
fer of data one word at a time under program control is too slow. The 
Datacraft operating system provides for Automatic Block Transfer Channel 
(ABC). After the ABC is initialized with information on size of block and 
storage locations, data is transferred twenty-four bits at a time without 
CPU action. An individual channel is capable of using one out of every 
three memory cycles for a rate of 333-k words per second. By means of 
special instructions, multiple channels can be overlapped to achieve an 
aggregate rate of one million words per second. 

Application Programs - Programs for DAPCS have been designed in modular 
fashion; i.e., usually each CAMAC module has a corresponding subroutine. 
Where several CAMAC modules are similar, more generalized subroutines have 
been designed. These subroutines reside as members of the disc library 
files and can be accessed by any program. 

The data word output from the software system to the CAMAC system is 
twenty-four bits in length. This is possible due to the compatabil i ty of 
the computers 24-bit word and the standard CAMAC 24-bit word. 

The six parts of the CAMAC command word are standardized as crate 
address (CR), station or module number (N), subaddress (A), function code 
(F), initialize (Z), and graded-L request (BG). These components of the 
CAMAC command word are arranged from the most significant bits to least 
significant bits (left to right) as follows: (BG), (Z), (F), (A), (N), and 
(CR). 

The CAMAC command words are given mnemonics that correspond to the 
CAMAC task to be performed. For example, the mnemonics for the command 
word to read the ADC Multiplexer for the fuel element-clamping-guide force 
(CR N Aq Fq) is RADCCG. Broken down, this is ^ead (F^) the ADC (N) for 
damping ^uide force (Aq). Similarly, RADCSR refers to _Read (Fq) the ADC 
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(N) for ^ense ^od position (A 2 )* The command words and their mnemonics 
are stored in the subroutine or program where they are used. 

The components (FAN CR) of the command word could be passed to the 
CAMAC driver with the actual command word put together in the CAMAC driver. 
This would eliminate the storage of command words i however, the same com- 
mand words would have to be assembled many times and the CAMAC driver would 
be lengthy. As indicated in the previous paragraph, the command words are 
defined and stored in the program where they are used. 

CAMAC Driver - The CAMAC driver for the DAPCS is a subroutine OUTWD. It is 
necessarily written in Datacraft assembly language. The efficiency afforded 
by the assembly language is also important because the CAMAC driver is 
called over 2-1/2 million times per Gamma Scan. In an average precision- 
gamma-scanning program, around 300 spectra are taken and OUTWD is called 
roughly 8300 times per spectrum. 

The main features of the routine OUTWD as the means of Implementing 
CAMAC commands are as follows: 

• OUTWD provides a standard method of addressing all CAMAC systems. 

All real-time programs are written in a similar way. Training 
required for new programmers is reduced and programming time 
required for experienced programmers is decreased. 

9 The subroutine can be called from a main program written in 
assembly language or a higher-level language such as FORTRAN, 

• Each time a command word is output to a remote crate, the on-line 
status of that crate is automatically checked. 

9 Handshake must be returned from the addressed crate before the 
program will continue. 

» A second try to output the command word is attempted if the hand- 
shake is lost because of electrical noise. 

• Transmission errors are checked for in either direction. 

• A second try to output the command word is attempted if a trans- 
mission error occurs because of electrical noise. This includes 
parity, framing, and stop/start bit errors. 

• The advantages of a subroutine such as OUTWD outweigh the over- 
head time in its execution. A nonmal execution of OUTWD takes 
approximately 100 machine cycles or 100 microseconds. 
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3.2.2 Fermi National Accelerator Laboratory 


3. 2. 2.1 General Description 

The Basic Instrument for the Support of On-Line Needs (BISON) system 
at Fermilab provides high-speed communication links using CAMAC equipment 
to interconnect two central CDC 6600 's with a variety of user minicomputers 
(mostly DEC PDP-ll's) in a multiplexed star network. The software system 
provides for efficient, transparent data transmissions between users and the 
central computers. For immediate data analysis, each experiment is allowed 
to transfer one 1024-word buffer from its minicomputer to the CDC-6600's, 
per accelerator cycle. The majority of the data are reduced and analyzed 
either by the controlling minicomputer with visual display or batch pro- 
cessed by the CDC-6600's. 

The intercomputer communication is by CAMAC modules which provide hard- 
ware independence. Each station consists of a transmi t/receive module and 
two 1024-word, 24-bit memories. One memory is the transmit memory and the 
other the receive memory. At the other end of two coaxial cables is a 
similar set of modules, and each set of modules is connected by a proper 
interface to a computer. This provides CAMAC-controlled computer-to- 
computer communication. This communication link is shown schematically 
in Figure 3-2. Figure 3-3 illustrates a typical PDP-11 BISON configuration. 

3. 2.2.2 Software System Description 

The Fermilab has developed a library of software to support the CAMAC 
instrumented experiments. A number of PDP-11 operating systems are used. 

In addition to operating systems provided by Digital Equipment Corporation 
(DEC), Fermilab has developed their own PDP-11 operating systems called 
SPEX and BSX. Of course, each experimenter must develop his specific appli- 
cation program, but Fermilab has many subroutines to aid in debugging pro- 
grams, handling data, displaying data, formatting, etc.. FORTRAN callable 
CAMAC handlers or drivers in assembly language are provided for several 
branch driver/PDP-11 interfaces. 

Fermilab has developed an interpreter to format desired CAMAC commands 
into Task tables that are then used by the CAMAC driver. This aids in tio 
development of application programs by the experimenters. 
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Figure 3-3. A Typical BISON PDP-11 Configuration 
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Operating Systems - As mentioned above, a number of operating systems are 
available to be used at Fermi lab. The PDP-11 operating systems include 
dec's Real-Time RT-11 disc operating system, DEC'S RSX multitask system, 
and Fermi lab-developed systems SPEX and BSX. SPEX is the spectrometer 
executive developed by Experiment 96 for use at the Meson Laboratory's 
Single-Arm Spectrometer. It is a core-resident multitask supervisor that 
swaps tasks in from the disc as they are required and frees core for addi- 
tional swapping as tasks exit. 

BSX is the primary operating system for PDP-11 's. It is a core-resident 
real-time interrupt-driven multitask supervisor that is operated with DEC'S 
DOS. The PDP-11 's trap directives are used to control the various Tasks, 
by changing the Program Counter (PC) and the Processor Status Word(PS). A 
trap is effectively an interrupt generated by software. When a trap occurs, 
the contents of the current PC and PS are pushed onto the processor stack 
and they are replaced by the contents of a two-word trap vector containing 
a new PC and new PS. 

Application Programs - Appropriate subroutines are provided at Fermi lab to 
allow FORTRAN application programs to operate in real-time. In addition, 
FORTRAN callable utility subroutines are provided to retrieve parts of 
words, shift bits of words, modify words, and work with specific addresses. 

The application programs used at Fermi lab are numerous and constantly 
changing, as contrasted to those at DAPCS where a few programs are used 
month after month. At Fermi lab there are two ways to implement CAMAC systems. 
One used the Kinetic Systems serial branch driver in an inexpensive data 
transfer approach. For the Kinetic Systems KS0011,;a table of directives, 
properly formatted, provide experiment contron and data transfer under pro- 
gram control (i.e., no hardware block transfers). The FORTRAN callable 
routine, KSOOll, transfers the desired CAMAC commands. 

The other method at Fermi lab for data transfer, including block trans- 
fer of data by Direct Memory Access (DMA), uses an EG&G BDOll branch driver 
and at least one DEC Device Register Interface (DRll-A). The BSX operating 
system provides for much of the task priorities, interrupt, and CAMAC 
handling. For example, a PDP-11 assembly language application program can 
define eight word task tables, define specific tasks, and proceed to accom- 
plish the tasks under program control solely by BSX. The trap directives 
are all FORTRAN callable. 
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While BSX can perform CAMAC handling, the general FORTRAN approach 
uses BSX through various subroutines. A labeled common (CAMCOM) of seven 
one-word integer variables is used to provide for "CAMAC BRANCH DEMAND 
interrupts," status of buffers, etc. 

The routine CAMVL is used to initialize the Branch Driver (BDOll) and 
up to four DRll-A's. This allows up to four high-priority (DMA) events; 
i.e., non-BDOll interrupts, to be initiated by DRll-A's. Included in the 
Call statement are the interrupt vector address and respective list of 
CAMAC commands for up to four interrupts. Also included is a word control- 
ling the mode in which event-associated CAMAC processing will be performed. 
The lists of commands are coded with the first five words defining event 
variable, maximum word count, release and initialization flags, and a "non- 
interrupt routine" address before the actual CAMAC commands which are 
regular BDOll crate selection-word count and instruction words. 

In addition to the above DRll-A interrupts set up by CAMVL and normal 
Branch Demand interrupts, explicit program calls to the routine CAMIO will 
initiate specified CAMAC operations. This provides for lower priority 
CAMAC operations. Up to eleven calls may be queued up at a given time and 
these tasks specified by task vectors will then be processed on a FIFO 
(first in first out) basis. 

Other FORTRAN calls are available to handle buffers, branch demands, 
errors, etc. and also to enable or disable the DRll-A interrupts, These, 
along with the FORTRAN utility programs, must have the task vector format 
to conform to the standard BSX task table. 

CAMAC Driver - The system does not have a directly identifiable CAMAC driver. 
The Operating System, BSX, in many respects serves the function of a CAMAC 
driver; i.e., CAMCOM (common block), CAMVL and CAMIO combine to establish 
the CAMAC command that BSX then passes to the branch driver (BDOll) and, 
hence, to the CAMAC system. Similarly, a call to KSOOll passes the desired 
command to the KSOOll branch driver. The call itself includes the list of 
commands coded per simple setup and action words. A standard FNA is in the 
action word while the crate number, number of CAMAC words to be transferred, 
and the control bits are contained in the setup word. This, within the 
established formats, both parallel and serial CAMAC branch drivers are 
FORTRAN programmable. 
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3*2.3 Los Alamos Scientific Laboratory 


3. 2.3.1 General Description 

The software system for data acquisition in experiments using CAMAC at 
Los Alamos is designed to support high-speed data acquisition on CAMAC sys- 
tems controlled by a PDP-11 via a microprogrammable branch driver (MBD). 

The software system provides CAMAC drivers for the PDP-ll/branch driver 
combination, utility routines and a special task-oriented language inter- 
preter to facilitate user application program development. 

The arrangement relative to the PDP-11 unibus is illustrated as Figure 
3-4. The dotted arrow indicates the additional six CAMAC crates that could 
be added to the system. The event trigger is a special CAMAC module that 
was designed to identify the various different classes of events, to facili- 
tate control and testing of the equipment, and to facilitate communication 
between different modules in the system. 

The MBD contains a full-fledged processor with an instruction time of 
350 nsec, eight priority structured DMA channels which share access to the 
CAMAC branch and unibus, and a sharable control memory {1024 words). The 
MBD controls the CAMAC branch, is capable of performing DMA data transfers 
to PDP-11 memory, and can interrupt the PDP-11. 

The MBD was required at Los Alamos because many of the experiments have 
high event rates and very high data rates. Their minimum system requirements 
are: two DMA channels for experimental data, one DMA channel to display accu- 
mulated data, and one DMA channel for communication with Los Alamos Meson 
Physics Facility terminal computers. 

The three major parts of the MBD are: the PDP-11 computer interface, 
the CAMAC branch driver, and the microprocessor. The computer interface 
has five 16-bit registers. These are: 1) memory address register (MAR), 2) 
memory data register (MDR), 3) control and status register, 4) program data 
register, and 5) mask register. The MAR and MDR are DMA channel registers 
controlled by the processor which controls the PDR-ll data during all DMA 
transfers. 

The branch driver is a conventional design with three basic registers; 
the T6-bit command register (CNAF), the 24-bit branch data register, and 
the 24-bit graded-L register. In order to get around the problem of the 
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Figure 3-4. Los Alamos Scientific Laboratory 
PDP-ll/CAMAC Data Acquisition 
System 
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command requiring seventeen bits, three different command types are defined: 
read, write, and control /test. Bit F8 is omitted from the command word and 
is provided by the processor. The processor is in complete control of the 
branch driver. 

The microprocessor is the control device that gives the MBD the speed and 
flexibility such that transfers between registers is faster and requires less 
hardware than with gates alone. The arithmetic and logic unit (ALU) is the 
heart of the processor and it connects the Source bus and the Destination 
bus. One microinstruction of the ALU transfers words between any of the regis- 
ters connected to the buses. An important function of the processor is to 
multiplex and control the eight DMA channels. In addition, the processor con- 
trols all communication between the CAMAC branch and the computer I/O. This 
frees the PDP-11 for use in real-time data computations. 

The Event Trigger Moudle provides for 32 external signals to be entered 
into the system via the CAMAC dataway on a priority basis. Receipt of an 
external trigger generates a Look-at-Me, causing the MBD data acquisition 
channel to begin execution, and it signifies that one of the 32 user-defined 
events has occurred. The trigger module also provides "busy" outputs that 
can be monitored. 

3. 2. 3. 2 Software System Description 

Operating System - The PDP-11 operating systems at Los Alamos are DEC RSX-llD 
or RSX-llM, interrupt-driven multitask supervisor systems. Where the Fermi- 
1 ab operating system (BSX) accomplished most of the CAMAC operations through 
task tables, at Los Alamos most of the CAMAC data acquisition is accomplished 
by the application program and CAMAC (QA) handler. Figure 3-5 is a simplified 
software block diagram. The operating system is involved with the tape unit, 
the display, disc histograms, core histograms, and the histogram display; i.e. , 
the computer non-CAMAC I/O functions. A portion of the QMBD, which is a 
resident data-acquisition MBD code, can also be considered part of the oper- 
ating system. 

Application Programs - At Los Alamos, the application programs which must be 
prepared specifically for each given application, and, hence, supplied by the 
user of the programs, are the event descriptions, the event processors, and 
the initialization sequence. The event descriptions are provided via a special 
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easy-to-use event specification language (Q system), while the event proces- 
sors and the initialization can be written as FORTRAN subroutines. 

An application program tailored for each experiment is referred to as 
an analyzer program and is written, translatad, and task-built with a standard 
structure. The end result is two files: one an object file containing the 
MBD code which acquires the data, and the other an RSX-11 task that processes 
the data acquired. Each analyzer program is given a name and is used else- 
where when referring to the particular analyzer. Each device is given a name 
and is unique by including a module name (e.g., KS3610, Kinetic Systems 3610 
scaler) and its address C, N, A, The module names must be part of the Q sys- 
tem which defines the legal CAMAC operations on the modules. Each event for 
the analyzer program is given a number, 0-23g, with 24-32g reserved for spe- 
cial system functions. Operand commands (e.g. , RD24, read 24-bit data) may 
be defined for multiple devices which were previously defined. Control and 
test commands may be specified. General CAMAC FCNA commands can be specified. 
The Q system translates the above and other normally- required CAMAC functions 
to produce the required data acquisition and data analysis files. The MBD 
does the data acquisition and the PDP-11 does the data analysis. 

What the above describes is a coded procedure to simplify the preparation 
of the application program. The specific steps or statements are defined in 
Los Alamos documents and must be followed with a certain rigor in order to 
satisfy the standard established format. The result is an efficient coupling 
of data acquisition using the microprogrammed branch driver (MBD) and data 
analysis using the PDP-11. 

CAMAC Driver - As implied in the preceding section on application programs, 
the Q system provides the required CAMAC driver. That is, the Q system at 
Los Alamos interprets the input command statements and develops the required 
code for the MBD to pass the desired commands to the proper CAMAC modules 

3. 2.4 Aluminum Company of America (ALCOA) 

3.2. 4.1 General Description 

The CAMAC support library for industrial systems at ALCOA provides an 
extensive library of computer-independent software modules to facilitate the 
development of diverse portable applications programs in standard ANSI FORTRAN 
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supplemented by standard ISA bit manipulation routines. A wide repertoire 
of computer/branch-driver-specific CAMAC drivers are available with a standard 
FORTRAN call sequence. A flexible logical device table generator scheme is 
included to handle diverse or variable hardware configurations with minimum 
software impact. 

In order to make the software system applicable to a diverse range of 
industrial process control applications using many different control proces- 
sors, a conscious effort has been made toward standardization; i.e., CAMAC 
hardware and ANSI X3. 9-1966 FORTRAN software. Application programs are nor- 
mally prepared in FORTRAN, and the hardware system support programs developed 
and cataloged by ALCOA are FORTRAN callable. In addition to the hardware 
system support programs; i .e. , computer-CAMAC driver programs ALCOA has high- 
level (FORTRAN) test programs, adaptor programs, and general utility programs. 

3. 2. 4.2 Software System Description 

Operating Systems - Specific operating systems are not required, and any sys- 
tem with a standard ANSI FORTRAN compiler for a given computer can be used 
within the operational limitations of that system. 

ALCOA has standardized their approach to CAMAC for various operating 
systems. This standard is based on use of four registers for interfacing 
(i.e. , computer bus to CAMAC highway) which are used for the following: 1) 
COMMAND, 2) ADDRESS, 3) DATA, and 4) STATUS. These generic information classes 
are kept separate and intact. The COMMAND register is used right-justified 
when mapped from register or data paths of more than five bits such as the 
computer I/O bus. As for the ADDRESS register, the bits are given right- 
justified as C, N, A. Twelve bits are used for a parallel highway* while 
fifteen bits are required for a serial highway. Each crate must have a unique 
address in the software and overall system structure. This becomes an "effec- 
tive" crate address in multi pie -highway systems and the translation between 
effective address and physical crate address on a particular highway must be 
done in the highway or computer-port selection software. For the DATA regis- 
ter, which requires twenty-four bits on the CAMAC side of the interface, 
sign extension is used with right-justified data bits when the computer word 
exceeds twenty-four bits and two or more non-CAMAC registers must be cascaded 
with sign extension for computers with less than24-bit words. So far as the 


97 



STATUS register is concerned, the following is the standard: a) the least 
significant bit indicates a No-Q response (i.e., it will be 1 if Q - 0), b) 
the next least significant bit indicates No-X response, c) the third least 
significant bit indicates a highway error, d) the next four bits are not 
to be used (reserved for future definition). A recoirmended option is that 
the eighth or higher bit be assigned as an "interface busy" bit. Then, 
when the software goes to read the status information, it can readily verify 
that the CAMAC operation has been completed. In most cases, the computer's 
sign-bit will be most useful for this purpose. 

Application Programs - Specific CAMAC process control programs at ALCOA are 
Usually high-level programs written in ANSI Standard FORTRAN X3. 9-1 966. 

These can be implemented by using a Logical Device Table; i.e. ^ a table 
formatted to assign a logical device number (LDN) to each device in a sys- 
tem. Utility programs are available to generate the LDN's, store this 
array in COMMON, and to modify the table of LDN's as required. Each LDN 
can then be used in the application program as the argument in calls to 
specific functional handlers; e.g., INTEGER FUNCTION INCHINT (LDN) which 
returns an integer value from the respective plug-in module's Group-1 regis- 
ter. Other FORTRAN callable functions or subroutines are used to handle 
data words in arrays, singly, or in bits; to test LAM' s; etc. 

ALCOA has implemented the ISA-S61.1 Procedures (Instrument Society of 
America) as the standard method for FORTRAN manipulation of bit strings. 
Programs are provided for various computers when the manufacturer of the 
computer does not provide for the ISA procedures. 

CAMAC Driver - There are many CAMAC drivers used at ALCOA; i.e, , one for 
each computer-branch driver combi rati on used. They are all used the same 
with simply CALL CAMAC (FUNCT,ADpR, DATA, STATUS). For multiple highway, 
the driver for each branch driver is renamed and CAMAC is then made as a 
highway selection code. 



3.3 SPACELAB SOFTWARE SYSTEM 

The primary hardware interface for data acquisition and control be- 
tween Space! ab and investigator-supplied experiment instrumentation is 
the Control and Data Management Subsystem (CDMS). This subsystem incor- 
porates a Mitra 125S general purpose computer that is dedicated to support 
of experiment operations. A complete set of software, including operating 
system and user program development bits will be available for that compu- 
ter. An overall description of the Spacelab software system from the user's 
standpoint is given in Section 4.5, Software, of the "Spacelab Payload 
Accommodation Handbook," ESA, May 1976. This material is reproduced in 
Appendix II for this volume. More detailed descriptions of the Spacelab 
software system and the CDMS operating system are contained in "Software 
Specification," SR-ER-0001 , ERNO, August 1975; and "CDMS Operating System, 
Package Design Specification," SS-ER-00T2, ERNO, September 1975. 

The software provided for users with the CDMS system covers all aspects 
of software development, integration, testing and operation, including in- 
flight command and data handling. A functional breakdown of the total 
Spacelab software system is shown in Figure 3-6. 

The investigator's experiment specific software or application program 
will interface with the experiment computer operating system (ECQS) and can 
make use of certain facility-type software incorporated in the flight 
application software packages (FLAP). 

The ECOS will be core-resident except for display routines and will 
consume approximately five percent of the computer execution time. It 
will handle the scheduling of tasks and allocation of resources with execu- 
tive routines for task schedul i ng , memory management, time management , 
computer resources management, and asynchronous task handling. 

In addition, it will provide the software interfaces (input/output 
drivers) to the remote acquisition units (the hardware interface between 
the CDMS and experiment instrumentation) , the CRT display units and the 
operator keyboards, as well as the standard peripherals. The primary use 
of FLAP for experiment operation will be in obtaining Spacelab subsystem 
operating information such as resource availability. 
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Figure 3-6. Spaeelab Software System Functional Breakdown 













The software development aids are designed for operation on an IBM 
370-series host computer. There are two HAL/S language compilers, one 
producing IBM 370 machine language and one producing Mitra 125S machine 
language. Programs in 125S language can be executed on a 370 with the use 
of a 125S simulator supplied as one of the development aids. There will 
also be two version each of a 125S macroassembler and an editor. One ver- 
sion will run on a 370 and the other will run on a 125$. A simulator 
running on the 370 for the entire CDMS exclusive of the 1253 will be 
available for program testing in conjunction with the 125$ simulator. 

Using the above set of development aids, the investigator will be 
required to write his experiment-specific programs in either HAL/S or 
in Mitra 125$ assembly language. Unfortunately, in spite of the complete- 
ness of the available software in terms of types of functions implemented, 
this is a serious deficiency from the typical user's point of view. No 
provision is made for users to write programs in any of the high-level 
software languages commonly used for laboratory data systems. Compounding 
this problem for the investigator who is willing to work in assembly lan- 
guage is the selection of a computer with which the typical user is totally 
unfamiliar. The user will thus be forced to invest in the necessary time for 
his programmers to become familiar with these languages. In addition, 
as is always the case when a new language is first learned, the efficiency 
of the programming effort will be low initially and the execution efficiency 
of the resulting code will also be less than optimum for early efforts. 

These potential problems will be somewhat alleviated if NASA is able 
to supply standard software modules to the investigators to handle routine 
repetitive operations such as accessing CAMAG hardware modules. As a 
result of these factors, it will be very important for NASA to supply as 
much standard software as possible to somewhat relieve the burden placed 
on individual investigators. 



3.4 CAMAC SUPPORT SOFTWARE FOR SPACELAB 


In investigating four existing approaches for software to support the 
the use of CAMAC hardware, it was found that several different concepts were 
used, sometimes even to meet similar requirements. The Spacelab experiment 
environment does not exactly match any of these four approaches and, in fact, 
includes some aspects of each. In considering the software requirements of 
the payloads analyzed in Task 2, a natural division into two distinct cate- 
gories was found. The first of these was the use of CAMAC to implement 
facility-type functions and the second was the use of CAMAC to implement 
experiment-specific instrumentation. 

3.4.1 Software for Facility Use of CAMAC 

The simplest of these two cases, in terms of selection of the best 
approach, is the facility use of CAMAC. In this case, the requirements 
change either very little or not at all as a function of time. The facility 
is reflown many times and accommodates new instruments from time to time but, 
in general, it supplies the same support functions on all flights. Because 
the CAMAC software is written only once and used for many flights, a some- 
what higher programming cost can be justified in order to achieve more effi- 
cient software performance in terms of resource requirements: execution 
speed and memory size. It is universally accepted that programming in assem- 
bly language can produce more efficient codes although at higher cost than 
if a higher-level language is used. Because of the nature of the long-term 
utilization of the CAMAC implemented facility-type equipment for Spacelab, 
the use of assembly language programs specifically tailored for each appli- 
cation is the best choice. Responsibility for preparing the programs will 
usually best be left with the facility hardware development organization. 

3.4.2 Software for Experiment Use of CAMAC 

For experiment^specific use of CAMAC, the variability of the software 
requirements means that software development will be a continuing process. 
Therefore, a convenient, user-oriented software system is preferable in 
spite of its reduced operating efficiency. In this case, a wider variety 
of techniques appears to be applicable, and the tradeoff among alternative 
approaches is not always clear. This uncertainty is exemplified by the 
choice of different approaches to solve similar problems in the four existing 
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software installations surveyed. In the case of Spacelab, however, there 
is one major consideration that clearly drives the choice. Because of the 
unfamiliarity of the typical user with the prdyratnming languages used with 
the Spacelab computer, the burden on the user can be greatly relieved if 
NASA provides a set of standard software modules that can be called in HAL/S 
for use with the CAMAC hardware. The resulting programs will not be as 
efficient in utilization of resources as the special ly-coded facility pro- 
grams discussed above, but the cost of preparing new experiment-unique soft- 
ware for each mission will be greatly reduced. 

The optimum system for reducing programming effort uses a hierarchy of 
several routines. The lowest level is a single CAMAC driver that provides 
the basic hardware/ software interface. This handler is very hardware speci- 
fic, depending on the computer and the CAMAC branch driver combination being 
used. It would be written in assembly language for the Mitra T25S and pro- 
vided as part of the ECOS and the simulators for the 370. If a standard 
branch driver is developed for use with the Spacelab CDMS because of the 
high degree of commonality expected for this system-common hardware element 
(see Section 3.1,1, Volume II), the development of a driver for the 1255/ 
branch driver combination would be a one-time effort that should be done in 
conjunction with the branch driver hardware development. 

The next level of subroutines would be the standard CAMAC software 
modules. These software modules would exist in a one-to-one correspondence 
with each type of CAMAC hardware module. They would be callable from HAl/S 
and, in turn, would call the CAMAC driver. They would allow reference to 
individual hardware units by means of logical unit number rather than physi- 
cal locations within the CAMAC crate system. In this way, the user software 
would be independent of the specific hardware configuration. The correspon- 
dence between logical unit numbers and hardware location would be established 
by an initializing routine prepared by the integrating contractor. This 
approach is best ilTustrated by the logical unit table generation scheme 
included in the ALCOA CAMAC support library. It would minimize the amount 
of software modification required when the hardware configuration is changed. 

The standard CAMAC software modules would be written in assembly lan- 
guage since they will be unchanging with time. In order to assure the auto- 
matic compatibility of CAMAC hardware modules with the software system, the 



standard CAMAC software module corresponding to each hardware module should 
be developed in conjunction with the hardware. 

The highest level of software would be the unique user-supplied appli- 
cation program. This would be written in the high-level language, HAL/S 
for each experiment and would access the CAMAC hardware by calls to the 
standard CAMAC software modules. The user program would generally consist 
of a main observation program along with at least two subroutines, one for 
instrument control and one for data acquisiton* 

The CAMAC handler and standard software module would be provided to the 
individual experimenter by NASA. Either the experimenter or his instrument 
contractor would prepare the experiment-unique software in each case. Al- 
though the resulting total software is not optimized in terms of execution 
time or memory size, it certainly provides the lowest risk development in 
terms of schedule and cost. 

The software cost impact of the use of CAMAC will depend on the host 
software environment which is available. If the complete Spacelab software 
system is available, the addition of the standard CAMAC software will greatly 
simplify the user effort devoted to input/output data transfers between the 
Spacelab computer and his experiment hardware, but this represents only a 
portion of the user's application program development task. The main advan- 
tage to the user would be the capability to write his applications program 
in direct correspondence with the hardware with which he is most familiar - 
the CAMAC modules used in his experiment rather than the Spacelab CDMS re- 
mote acquisition units. If convenient, user-oriented, input/output drivers 
for the Spacelab RAU are available in the Spacelab software system, the 
cost differences due to the use of CAMAC equipment will probably be slight. 

On the other hand, if the available Spacelab software support is limited or 
inconvenient to use, the availability of standard CAMAC software can save a 
considerable amount of the user effort that would be required to develop 
special input/output drivers specifically for his experiment. 
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3.5 SOFTWARE REQUIREMENTS FOR REPRESENTATIVE PAYLOADS 


The Shuttle Infrared Telescope Facility (SIRTF) and the X-ray/Gamma- 
ray payload were selected as specific examples to illustrate the software 
implementation for payloads using CAMAC equipment. 

3.5.1 Shuttle Infrared Telescope Facility Software 

3. 5. 1.1 Major Categories of SIRTF Software 

In considering what is needed to operate SIRTF during a Shuttle flight, 
it is evident that two major categories of software functions are required. 
The first is that which monitors and controls the operation of the telescope 
facility, itself, and the other is concerned with data processing and con- 
trol of whatever focal plane instruments are being used in the observations 
being performed. The software in each of these two categories operates 
mostly independent of that in the other category and the treatment of each 
category as far as the creation and configuration management of the programs 
will be different. 

A wide assortment of programs and subroutines will be required in the 
category of facility software. An automatic initialization routine will be 
necessary to activate the telescope after the Shuttle has been launched and 
has arrived on station. This will include operations for uncaging and 
starting cryogen flow. In association with this initialization routine, 
another program will be required to perform an automatic checkout and setup 
of the telescope including such functions as focusing and establishing opti- 
cal alignment using a laser source. This latter function is especially 
critical because the telescope will be incapable ofadequate alignment until 
it experiences zero-g environment. Additionally, there must be a facility 
program to handle the overall pointing and control of the telescope during 
operation. This program must interact with the Orbi ter attitude control 
programs and with the observation programs for the individual experiments. 
Finally, an automatic shutdown program will be required that cages the tele- 
scope and safes the facility in preparation for landing. 

The software associated with each of the individual experiments will 
be primarily concerned with providing operational control to the instruments 
and processing the data from the infrared observations. The routine that 
governs the overall data gathering operation must interact both with the 
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data processing program for the instrument and with the facility telescope 
pointing programs. Additionally, the experiment software must provide for 
the display of experiment data on the Spacelab CRT's and also be able to 
interpret inputs from the Spacelab keyboard. 

In order to determine the applicability of modularized CAMAC software 
to SIRTF, consideration must be given to the different characteristics of 
the two categories of software. 

Specifically, since the software associated with the facility is inde- 
pendent of whatever instruments might be mounted in the focal plane, it will 
be developed as a part of the development of the facility on a one-time, non- 
recurring basis. The software associated with the focal plane instruments, 
however, will change with each new instrument and will continue to be modi- 
fied as the experiments are modified. These considerations indicate that 
the facility software is better developed uniquely for each of the facility 
requirements and that it is only in the case of the experiment software that 
benefit might be had from the modularized concept. 

Additionally, it should be pointed out that the modular CAMAC concept 
in the software presupposes the existence of CAMAC hardware with which to 
interface. In Section 3.3 of Volume II, it was seen that except for the 
housekeeping and fine pointing functions, all of the application of CAMAC 
hardware was to the signals from the focal plane instruments. There was 
very little applicability for CAMAC in the rest of the facility. 

For these reasons, the analysis that follows will concern itself with; 
the application of CAMAC modular Software to the instrument-related category 
of SIRTF software almost exclusively. The only exception will be that the 
facility housekeeping and fine pointing functions will also be considered. 

3. 5. 1.2 SIRTF Software Requirements and System Design 

The specific software functions required to support the operations of 
the five SIRTF instruments are analyzed below. Also included is an analysis 
and discussion of what is required to operate the housekeeping and fine 
pointing systems if they were implemented with CAMAC hardware as discussed 
in Task 2 of this study. 
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Filter Photometer - Operation - When the filter photometer instrument is 
flown, it will have a preplanned program of observation to execute. This 
program will be established based on prior knowledge of Shuttle orientation, 
sun-moon-earth positions, and the requirements of other instruments during 
that mission. The observation of a single object (target) will proceed as 
follows: 

The payload specialist will tell the experiment computer (via keyboard 
input) that he is ready to move to the next object in the filter photometer 
observing program. The computer retrieves the coordinates of that object 
from the mass memory and from the Orbiter computer, gets the current orien- 
tation of the Shuttle. From this it computes the operations necessary to 
acquire the target and display it for the payload specialist. After the 
target area has been acquired, the computer retrieves from mass memory and 
displays for the payload specialist instructions about how to observe the , 
specific object. This will include finding charts (to aid in fine pointing 
acquisition), expected signal levels, filters and apertures to be used, and 
any special instructions for carrying out the observation. 

The payload specialist will then perform the fine pointing functions 
necessary to acquire the particular object to be observed within the target 
area. The detailed operations required for this acquisition will depend on 
how the facility ultimately provides for fine pointing control (e.g. , joy- 
stick, keyboard input, pushbutton). 

Having acquired the object, the payload specialist will call up the 
observation mode program in the experiment computer and input the parameters 
necessary to perform this observation. These parameters will include speci- 
fying the amount of time to observe the object before moving to a nearby 
piece of background sky and the number of times to repeat the object-sky- 
object cycle. He will also specify the sequence of filters and apertures to 
be used in making the observation* In one mode of observation, he may re- 
quire that a particular signal-to-noise ratio be attained before moving to 
the next filter and aperture selection. 

Having made these inputs, he will initiate the observation process that 
wi 11 then proceed under computer control .As the observation is made, the 
experiment computer will perform all routine monitoring of instrument status 
parameters and control the fine pointing of the telescope. The computer 
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will also perform real-time processing and display of the infrared data 
and, via its interface to the Orbiter, output this data to the telemetry 
system. ‘ 

Filter Photometer - Software Requirements - The major software functions 
required to operate the filter photometer as just described are shown in the 
top level system diagram of Figure 3-7. The Spacelab computer system is 
indicated on the left of the figure and the CAMAC hardware used to support 
the facility and the filter photometer is shown on the right. Each of the 
blocks in between represents a module of software operating within the ex- 
periment computer. The diagram does not show the separate subroutine that 
is used for the initial retrieval of information from mass memory to give 
the payload specialist the background information required for each 
observation. 

The central control of any given observation resides in the observation 
mode program. This program receives the keyboard instructions of the pay- 
load specialist and uses them to execute the details of the observation. 

In order to do so, it must interface with the facility subroutines for fine 
pointing and housekeeping so that it can control the telescope. It also 
must interact with the subroutines that process the data from the photometer 

since it reacts to the signal -to-noise ratio of the infrared detector and to 

other of the instrument parameters in determining the amount of time to be 
spent on any given measurement. 

The data acquisition subroutine is specifically oriented toward the 
filter photometer. It contains all of the data reduction parameters and 

computation algorithms necessary to process the signal from the infrared 

sensor. By accessing the CAMAC module subroutines, it gets the digitized 
data from the sensor. Information about filter position, aperture and 
photometer temperatures are obtained from the instrument control subroutine. 
Pointing and frequency of spatial chopping data come to it through the ob- 
servation mode program. Upon request it provides processed data to the 
payload specialist. 

The instrument control subroutine monitors the status of the photometer 
and generates control instructions for the selection of filters, choice of 
apertures, and the insertion of the blackbody calibration source into the 
beam. It accesses the CAMAC module level subroutines as required to 
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Figure 3-7. SIRTF Software System Diagram 








retrieve data from the photometer and generate control signals. Upon re- 
quest by the observation mode program, this subroutine provides the instru- 
ment status parameters for display or changes the instrument configuration 
for the next stage in the measurement process. 

Both the data acquisition subroutine and the instument control subrou- 
tine communicate with the photometer through the CAMAG module level subrou- 
tines. There is one of these for each module in the CAMAC crate supporting 
the photometer functions. They, in turn, access the hardware through a 
CAMAC driver that is used in common by all of the CAMAC module software. 

It is this driver that forms the software side of the software-hardware 
interface in the CAMAC system. 

The display and keyboard subroutines shown in the figure handle the 
details of operating those two pieces of hardware. If CAMAC is used in 
these systems, then they also would be accessing module level CAMAC sub- 
routines. 

The fine pointing and housekeeping subroutines interact with observa- 
tion mode program for control of the telescope facility. They will be dis- 
cussed separately in a later section. 

Filter Wedge Spectrometer - As discussed in the earlier analysis of this 
instrument, it is essentially identical operationally to the filter photom- 
eter. It would require identical software and could be operated in the 
same fashion except that measurements at many more filter positions would 
be required. 

Grati ng Spectrometer - The primary difference between this instrument and 
the filter photometer is that here the observation mode program and the 
instrument control subroutine must use and control the grating in the instru 
ment. The particular spectral settings used in a given measurement will 
vary depending on the nature Of the object and the purpose of the measure- 
ment. The choice of these settings will be input to the observation mode 
program by the payload specialist at the beginning of each observation. 

The data acquisi tion subroutine will have to incorporate the grating 
orientation into its interpretation of the signal from the sensor. Other- 
wise the grating spectrometer requires the same software and operates in 
the same fashion as the filter photometer. 
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Detector Array - As discussed in an earlier section, the detector array is 
functionally identical to the filter photometer except that it generates 
256 identical signals and allows simultaneous measurement and mapping of 
many points in a region of interest. Each of the 256 signals may be thought 
of as that from a single filter photometer and is processed in an identical 
fashion. However, the capabilities of the data processing subroutine must 
be much expanded to handle all of these signals at one time. It also must 
average the signal-to-noise calculation over the entire array of signals 
in order to present reasonable signal-to-noise information to the observa- 
tion mode program. The display software for this instrument should be 
capable of presenting the infrared map of the target area as it is accumu- 
lated by the sensors. The only difference in the instrument status subrou ^ 
tine from that for the filter photometer is that control signals must be 
provided to operate the pulse generator which clocks signals out of the 
detector array. 

Fourier Spectrometer - The software system required to operate the Fourier 
spectrometer is organized the same functionally as that shown for the filter 
photometer. However, the operations performed in the observation mode pro- 
gram, data processing subroutine and instrument status subroutine and the 
uses made of the fine pointing are significantly different from those in 
the filter photometer system. The primary reason for these differences is 
that in this instrument the mechanical operation which causes the signal 
variation detected by the infrared sensor is the motion of the Michelson 
mirror in the instrument itself and not the spatial chopping with the second 
folding flat of the telescope. 

One major result of this difference is that in this system the instru- 
ment control subroutine must be more sophisticated than a photometer- type 
system. It must precisely control the motions of the Michelson mirror and 
must continually keep the data processing subroutine informed of these 
motions. In turn, the latter subroutine will have to precisely coordinate 
its samplings of the sensor output with the movements of the mirror. A 
sizable data storage array will be required in which to accumulate the 
samples from each of the different mirror velocities. In order to present 
the data as a spectral distribution, the data acquisition subroutine will 
either have to contain a fast Fourier transform algorithm or be able to 
call upon one in the Spacelab software system. 
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The observation mode program for the Fourier spectrometer will main- 
tain overall control of the measurements but will not be as directly in- 
volved in the measurement process as it was in the photometer system. Once 
it has put the object in the spectrometer aperture by controlling the fine 
pointing system, it essentially turns control over to the instrument control 
and data acquisition subroutines until the measurement is complete. At that 
point, it resumes control and may call for a display of the spectrum or may 
repoint the telescope at a nearby section of sky to take a background 
measurement. 

Housekeeping and Fine Pointing - The software to monitor the facility house- 
keeping signals and to control the fine pointing of the telescope will operate 
within the experiment computer and interface into CAMAC equipment but because 
it is a permanent part of the facility and independent of whatever focal 
plane instruments are flown, it will be structured somewhat differently from 
the CAMAC software associated with the instruments. In order that they may 
be readily modified as the facility evolves and in order to be more easily 
adapted to the various observation mode programs, the fine pointing and 
housekeeping functions will be handled by separate subroutines. However, 
instead of calling CAMAC module level software to interface to the hardware, 
these subroutines will access a facility interface routine which itself 
directly accesses the hardware. 

The facility interface routine is written in the assembly language of 
the computer. It is effectively an amalgamation of the CAMAC routines and 
the CAMAC driver. In the case of facility software, this amalgamation is 
acceptable because the hardware system is fixed and not continually being 
reconfigured as it is for the instruments. Because the facility interface 
routine accomplishes the software/hardware interface in a single assembly 
language stage, it is more efficient than the corresponding interface in the 
instrument software system. 

The fine pointing subroutine itself performs all of the real-time 
functions necessary to close the control loop on the orientation of the 
second folding flat of the telescope. Through the interface routine, it 
relies heavily on the real-time interrupt capabilities of the computer to 
react to changes in the pointing status of the telescope as they are detected 
by the quadrant error sensor. 
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The housekeeping subroutine also depends on the real-time interrupt 
structure of the computer in that it must respond to any changes in status 
of the parameters it monitors. Additionally, it performs regular, routine 
checks of all signals in the housekeeping system and stores processed 
values for presentation to the observation mode program upon request. 

3. 5. 1.3 CAMAC Module Software Requirements 

The requirements for CAMAC module level subroutines can be derived in 
a straightforward fashion from the requirements for CAMAC hardware that 
were established in Task 2 of this study. Table 3-1 is a software require- 
ments analog of Table 3-16, Volume 11, which summarizes all of the CAMAC 
hardware requirements for SIRTF. 

The one difference in the software table is that there is no need to 
indicate the number of module subroutines of a given type that are required 
for each instrument. At most, only one of each type will be required no 
matter how many modules of that type are used in the hardware system. This 
reflects the fact that a single CAMAC module level subroutine can be used 
to service many hardware modules. For each module, the subroutine is called 
with an argument that specifies which hardware module is to be serviced. 

The only modules for which separate subroutines may be required are the 
fast ADC's used in the detector array. This will depend on the frequency of 
sampling for that system which in turn depends on the frequency of spatial 
chopping that is used, It should also be noted that a separate type of sub- 
routine is specified for the multichannel ADC's due to the slightly different 
software structure required by the added complexity of addressing a specific 
ADC channel . 

Because the housekeeping and fine pointing systems access a custom- 
designed interface routine as discussed earlier, they are not listed in the 
table. Since they are the only subroutines that access digital-to-analog 
converter modules, no module level subroutines for this function are required 

Not shown in Table 3-1 is the CAMAC interface level subroutine referred 
to as the CAMAC driver in Figure 3-7. This assembly language program accom- 
pl ishes the detai led interface of the software system to the hardware system. 
It is accessed by all of the module level subroutines and is, therefore, 
required in the software system of every instrument. 



Table 3-1. SIRTF CAMAC Software Module Requirements 
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The CAMAC module level subroutines and the CAMAC driver will be fur- 
nished to each instrument as a part of the package including the CAMAC 
hardware modules required by that instrument. After selecting his hardware 
modules, the experimenter for each instrument will also receive a user's 
guide to the module level subroutine associated with each piece of hardware 
he has chosen. Reference to these user's guides will greatly simplify the 
generation of his data acquisition and instrument control subroutines. 


Additionally» the housekeeping and fine pointing subroutines together 
with the CAMAC -oriented facility interface routine are available to each 
experimenter. This will allow him to accurately control the fine pointing 
of the telescope by high-order software operations. He will not require a 
detailed knowledge of the subtleties of the fine pointing control loop or 
the intricacies of the software-to-hardware interface for this control. 
Similarly, all of the housekeeping and status information from the facility 
will be readily accessible to him either by calling the subroutine ur by 
having the status variables passed to him in common. 

Finally, the software necessary to drive the I/O units (keyboard and 
CRT display) will be part of the software package available to each experi- 
menter. As mentioned previously, these will include the appropriate CAMAC 
module level subroutines if CAMAC is the hardware standard used to implement 
them". 
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Thus, only three major elements of the software need be rewritten for 
each of the instruments. These are the observation mode program, data 
acquisition subroutine and instrument control subroutine. These can all 
be written in the high-order language of the experiment computer and all 
of their interface to the hardware will consist of simple calls to the 
appropriate subroutines. The use of CAMAC and facility software thus mini- 
mizes the software effort required as different instruments are developed 
for use in SIRTF. 

3,5,2 X-Ray/ Gamma -Ray Pallet Payload 

3. 5. 2.1 Major Categories of X-Ray/ Gamma- Ray Pallet Software 

The X-Ray/ Gamma Ray Pallet is composed of three independent instruments 
primarily intended for preprogrammed automatic operation. They require no 
specialized facility support from the Spacelab beyond the normal resource 
provisions and pointing capability. Because of these factors, no facility 
software is required to support the operation of these instruments other 
than the standard operating system for the Spacelab experiment computer. 

Each instrument does, however, require a unique set of experimenter-provided 
software which can readily be partitioned in the manner recommended in 
Section 3.4. The programming effort required to develop this unique set of 
software would be greatly reduced if the recommended set of standard soft- 
ware modules were supplied to the experimenter by NASA. 

3.5. 2. 2 X-Ray/ Gamma “Ray Pallet Software Requirements 

Because of the similarity of the software requirements for the three 
instruments that form the X-ray/Gamma-ray pallet, Figure 3-8 can be used to 
represent the software and hardware interrelationships for each instrument. 
As shown in Section 3 of Volume II, all electronic requirements for these 
instruments can be satisfied with NIM and CAMAC hardware with the exception 
of a limited number of amplification and power supply requirements. In 
particular, all data and control interface functions are implemented with 
CAMAC modules and this interface is represented by the block at the far 
right side of Figure 3-8. The software interface is provided by a standard 
NASA-provided CAMAC driver. In addition, a set of standard, NASA-provided, 
CAMAC module level subroutines are used to reduce the programming effort 
for the instruments. These subroutines provide access to the individual 




Figure 3-8. X-Ray/Gamma-Ray Pallet Payload Software System Diagram 
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CAMAC hardware modules from a high-level programming language on a one-for- 
one basis. 

The only unique softere that the experimenter must provide for an 
individual instrument is the main observation program and its associated 
instrument control and data acquisition subroutines. This set of unique 
software is executed in the environment of the Spacelab experiment computer 
system hardware and software and calls the standard CAMAC software modules 
as required. 

Large Area Proportional Counter Array - The Large Area Proportional Counter 
Array has very few control requirements. In the normal data acquisition 
mode, the instrument is completely passive, responding on an event-by-event 
basis to detected X-rays. Attitude control operations, including pointing 
at sources and scanning regions of the sky with the optional modulation 
collimators, are provided by the normal Spacelab facility capability. 

The instrument control subroutine satisfies two housekeeping- type 
functions. The ongoing activity is the maintenance of the gas pressure in 
the MWPC's within pre-established limits. This requires periodically mea- 
suring the pressure in each of the ten MWPC's by means of the transducers 
connected to CAMAC ADC's. When the pressure falls below the desired range 
for a given MWPC, the gas supply valve is actuated by a CAMAC output driver 
until the pressure reaches the upper limit of the desired range. The cali- 
bration function is an infrequent operation occurring at preprogrammed 
times. CAMAC stepping motor drivers are used to position radioactive sources 
in front of each MWPC and CAMAC position encoders are used to determine the 
exact source position in each case. These sources are left in front of the 
MWPC's for a fixed length of time and then retracted so that normal data 
taking can resume. The instrument control subroutine would utilize four 
standard CAMAC software modules, one corresponding to each type of CAMAC 
hardware module mentioned above, in addition to the standard CAMAC handler. 

The data acquisition subroutine can react to the occurrence of an 
event in one of two ways, depending on how the event trigger is implemented 
in the hardware. If the instrument is assigned to a computer interrupt, 
event data can be acquired on a prioritized demand basis. In this case, the 
data acquisition software must be prepared in the form of an interrupt sub- 
routine wi th appropri ate entry, exit and register save functions as required 
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by the operating system. If the instrument uses a CAMAC input register for 
setting an event flag, then that CAMAC module must be periodically polled 
at a rate that is significantly higher than the expected event rate in order 
to avoid substantial counting rate type losses. The polling function can 
probably best be performed at the system level rather than by periodically 
calling a user-supplied program. In this case, the data acquisition sub- 
routine could be activated by a software generated interrupt or in a less 
direct context change, by the time sharing system. 

Once activated, the data acquisition subroutine would access the CAMAC 
hardware modules to recover the event specific data and the updated scaler 
values not directly associated with the occurrence of an event. This data 
would be buffered in the memory for logging to permanent storage and also 
made available to the instrument observation program. After obtaining the 
event data, the data acquisition subroutine would perform any necessary 
resetting and clearing of data buffers in the CAMAC hardware to prepare 
the instrument for the occurrence of the next event. A total of four types 
of standard CAMAC software modules are required to perform these data acqui- 
sition functions. 

The observation program would coordinate the activities of the instru- 
ment control and data acquisition subroutines, in particular during cali- 
bration sequences. It would also provide for any on-line preparation of 
the data for quick-look displays used to verify proper operation of the 
i nstrument. 

Bragg Crystal Spectrometer - From the standpoint of the software, the Bragg 
Crystal Spectrometer can be treated as two separate instruments, with the 
low-energy and high-energy spectrometers operated independently. In the 
normal data acquisition mode, both spectrometers respond to detected X-rays 
on an event-by-event basis. The instrument contrcl subroutine must provide 
active control of the crystal position during data acquisition. The crystal 
is stepped through a preprogrammed series of positions to provide energy 
spectrum information and this observation cycle is repeated periodicaTly. 
Attitude control operations are carried out by the normal Space! ab facility 
capability and are coordinated with the crystal observation cycling. 

In addition to controlling the crystal positions during experiment 
observations, the instrument control subroutine also provides for gas 
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pressure control in each of the MWPC's and performs calibration operations 
for both spectrometers. From a software standpoint, these functions are 
identical to those described for the Large Area Proportional Counter Array. 
In total, the instrument control subroutine would use four standard CAMAC 
software modules. 

The data acquisition subroutine would be written to correspond to the 
specific hardware configuration of CAMAC modules used for the spectrometer. 
Its operational concepts and functions provided, however, would be identical 
to those discussed for the Large Area Proportional Counter Array. A total 
of four standard CAMAC software modules would be used for the data acquisi- 
tion subroutine. 

The observation program would also be similar in functional concept to 
that for the previous instrument. Any on-line data reduction and quick- 
look displays would, of course, be specifically tailored for this instru- 
ment. In addition, the observation program for this instrument would have 
to provide for the coordination of the crystal observation cycles and the 
Spacelab attitude control . 

High-Resolution Gamma-Ray Ge(Li) Spectrometer - The software requirements 
for the High-Resolution Gamma Ray Ge(Li) Spectormeter are not as extensive 
as those for the preceding two instruments, although the basic concepts are 
the same. The only function performed by the instrument control subroutine 
is the maintenance of the proper temperature environment for the optimum 
performance of the solid state detector. This subroutine requires two 
standard CAMAC software modules. 

The data acquisition subroutine again responds on an event-by-event 
basis as for the previous two instrumehts. It uses three standard CAMAC 
software modules. The observation program deals primarily with the data 
acquisi ti on subrouti ne si nee the temperature control provi ded by the instru- 
ment control subroutine is a continuous, unchanging activity except for 
periodic assessment of housekeeping data. 

3. 5.2. 3 CAMAC Modul e Software Requi remen ts 

The X-Ray/Gamma-Ray Pallet requirements for CAMAC module level subrou- 
tines are summarized in Table 3-2. A total of ten different module subrou- 
tines are used. As described in the SIRTF payload discussion, each 
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Table 3-2. X-Ray/ Gamma -Ray Pallet Payload CAMAC 
Software Module Requirements 

Instrument 


CAMAC Module 
Scaler 

Position Encoder 
Input Register 
Output Driver 
Stepping Motor Controller 
Time Digitizer 
ADC's 
DC level 

low-resolution pulse 
high-resolution pulse 
DAC 


Large-Area Bragg High-Resolution 

Proportional Crystal Gamma-Ray 

Counter Array Spectrometer Spectrometer 


subroutine is used on a shared basis for all hardware modules of that same 
type. Thus, although over 100 CAMAC hardware modules are utilized for 
this payload, the ten standard subroutines listed in the table, combined 
,with the single standard CAMAC driver, satisfy all software interface 
requirements. 

3 . 5 . 2 . 4 CAMAC Software Appl i cabi 1 i ty Summary 

As was found in the case of the SI RTF payload, a significant program- 
ming burden, and consequently cost, can be removed from the individual 
investigator using the X-Ray/Gamma-Ray Pallet if NASA supplies standard 
CAMAC software modules corresponding to the hardware utilized. In this way 
the individual investigator is freed from the hardware/ software interface 
manipulation requirements and can concentrate on his observation mode pro- 
gram and its associated data acquisition and instrument control subroutines 
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CAMAC SOFTWARE PRODUCTS GUIDE 

INTRODUCTION 


The Software Products Section of the CAMAC 
Products Guide lists a number of software packages, 
programs and routines which have been developed 
by software firms, manufacturers of CAMAC 
equipment, and at research laboratories. 

Work is going on to implement IML — the inter- 
mediate level CAMAC language. One contribution 
to IML implementation is listed below, but at least 
five other laboratories are at present engaged in 
implementing IML on several computers. 

The products listed below are either in current 
use or will be so in the nearest few months. Some 


of the software listed is commercially available, 
information about other is presumably available 
from respective authors. The correctness of each 
entry has been carefully checked against data 
provided. 

Inclusion in the list does not necessarily indicate 
endorsement, recommendation or approval by the 
ESONE Committee, nor does omission indicate 
disapproval. 

The classification used tentatively and reproduced 
below, is the same as was proposed in the March 
1974 issue (No. 9) of this Bulletin. 


SOFTWARE CLASSIFICATION GROUPS 
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.50 Fundamental Concepts, General Subjects 


SLHVlCt 
CL*SS coot - 
TITlt- - • • 
»UTH0R(S)- - 

PUBL, HtF, • 


RtF MCI H.SOOl 
.SO 

IRPLfMtNTINC C*"*C BV CDHRIttHS 
", PNtlS, SFK, iYSLUTHON-UB,, 
KARLSRUHE, OERHANY 
PRUC CAHAC SYMPUS, LUAMfiC, DEC IS7J 


OtSCRIPtJUN" • 

DtMAKnS UN HkALwIIPt SySItHS SUCH AS HiNlMUH tAttUlIUN TlHt 
HlMHUH tUHt HtUUlHEHk'NTS, ETC,, RtCUMntNO ThE USE UF LDH- 
PILERS IR PKUSHAHMiNt,, THE PUSSIBILIIY lU IHPLEhlM A Ca"AC 
LANCUAGi BY A COMPILER IS H"SI UF ALL A FUNCTION UF TnE 
LEVEL ANU CONCEPT UF TnE LANbUAGE, HE T AvLANUUAGES , THE SYN> 
TAX UF A PHUGRAMnlNG LANGUAGE, ARE USEU TU FUHHULAIE A CuH« 
piler fur a specific language, The HeThUU uESCKIBEU has 
BEEN USEU TU "HUE A CUHRILER FOR IHL, THE IMERhEUIaTE lEvEL 
CAmAC LANGUAGE, IHRLEHENIEU IN AN ASSEMBLER ENVIHUNHEM , 


reader service 
CLASS CPOE . 
TITLE" • • - 

aOTHUR{S)" » 

PUBL, REF, • 


REF nU 14,5002 
.50 

PROCEDURE CALLS • A PRAGMATIC 
APPROACH 

J, RICHElSON, M, HAtLiNG, 

KFA, jue:lich, 

PRUC CAHAC SYHPUS, LUXMBC, UEC IRFJ 


F.SUNE REOSTH date 31 HAY I97A 


DtSCRIPTIUN. . 

DISCUSSIUN UF RRUCEUURE CALLS AS THE BASIS FUR CAHAC SUF I "ARE 
rIThIn HiCH"LEVEL LANGUAGES, CUHPaRISUN "ITh STnTax HuCUI" 

catiuns to languages, discussion UF IHPlEHENTATIUn 
restrictions out TU language REOUIREHENTS FUR EXISTING HIGH" 
LEVE'L languages, E|G| CLUStO STSTEH"SUBRUUTInES HHlCH EXE" 
CUTE ONE defined UPERaTIUN (INVOLVING UNE UR MURE CAMAC 
CYCLES AS A GROUP), LUhPARISUN OF US"N1H CAHAC FURTRAN 
subroutines ANU RHUCEDUHE"CALL syntax UF ESUNE S"C IML 
LANGUAGE, aRPLIC'ATIUN UF RRUCLDURE«LALUS TO ARPlUAIIUN" 
oriented SUF TaaRE, 


READER service 
CLASS CUDE * 
TITLE" " " " 

AUThOR(S)" - 
PUBL , REF , • 

NAHE/ACRUNYR • 
OPERATIVE DATE- 

computer • 

INTERFACtCS) • 

softrare type « 

INCURP technique 
facilities • 


REF NU 14,5003 

, 601 (PL"in 

CAHAC FACILITIES IN THE programming 

language of PL"1I 

RUBERT D RUSSELL, CLRN, GENEVA 

PRUC CAHAC SYMPUS, LUXMBG, UEC 1RF3 

YELLO" REPORT, CERN 74-2A, UEC lR/4 

extended PL.ll 

1971/7J 

POP"ll, "ORD LENGTH JS HITS 
CA-U (EClG/ORTtC) 

LANGUAGE, PL'IICEXTENDEO) 

IN"LIN£ CODING OF CAHAC STATEMENTS 

symbolic device name used 
demand handling 1$ INCLUDED 


DESCRIPTION" • 

RL"U IS An IN!ERmE01ATE"LEVEL, HAChInE-URIENTEU PhUGRAMMINC 
language extended TO include CAMAC F tA I UMtS , STMAC 1 1 L F URH 
UF CAMAC statements ARE ANALUSUUS TU SIAnDaRu RL"11 STATE" 
mEnTS, symbolic names FUR VARIABLES AND FUNITIUNS ARE OE" 
CLAMED AT Once, AND ORERaTIUNS ARE EXECUTED BY STATEMENTS 
referring TU THESE NAMES, USE UF STHbULtC NAMES MAKES PMU" 
CRAMS READABLE, ANU SIMPLIFIES mUOIF^CAT 1 UNS UF CAMAC LON. 

figurations, 

ERAMPlE UF standard STaIEmENI". 

"H.ILE PRINT3TATUS • BUSY DU 
ERAMPLE of CAMAC STATEMENT"" 

"HILE CRTStATUS P BUSY DU 


READER service REF NO 14,5004 

CLASS CODE . ,B01 (CATV) 

AUTHUR(S)" « F R COLDINC, OARLSBURY LRBURATURIbS 

NAME/ACRDNYM • CATY 

COMPUTER • ANY 

SOFTRARE TTPE • L*NGUAGE (OAStD UN BASIC) 


DESCRIPTION" . 

CATY is a MALHInE independent hIGH«LEVEL language BASED UPUN 
A SUBSET OF BASIL "ITH EXTENSIONS FUR ADDRESSING CAMAC, 
RHUGHAMS written )N CATY ARE CUMRILED ANU NUT INTEHRkEIED, 
THUS, THE SPEED UF URERaUuN "HEN CAHaL IS TESTED UNOE" LAtY 
IS CUMPAMABLE "ITH The SPEED OF OPERATION IN ARRtlLA I lUNS , 
CATY HAS BEEN IhRlEMEMED UN- SEVERAL CUHRUIERS (SEE ,b4JI, 


READER SERVICE RtF NO 14,5005 

CLR5S CODE • ,501 (C*TY) 

title- - • • specification UF THE LRNGUaGE CATT C1O30 

AUTHUR(S)" • R F CRRNritLD, GEC ELlIUTT 

(SEE ALSO PREVIOUS ENTRY) 

NAME/ACRONTM • CATY 

OBTAINABLE FHUh. GEC ELLIOTT (SEE LIST UF hanUF ACTURERS ) 

available UN/AS" DESCRIPTION 

SOFTRARE TYPE" LANGUAGE (BASED ON BASIC) 


header SERVICE REF NO 14,6006 

CL45S CODE • ,501 (IML) 

TITLE- - - • the definition UF IML 

A LANGUAGE FOR USE IN CAMAC SYSTEMS 
prepared by . EsONE cummittee, softrare r,G, and 
AEC NiM cohhittee, software ",G, 

PUBL, RfF, " REPORT ESUnE/ImL/0 1 , UCT 19/4, AND 

report IID-26615, JAN 1975 
NAME/ACRUNTM • IML 

maintenance BY" ESONF CUHMITTEE In COLLAHURATIUN 

"ITh NIM committee 

CIBTAINABLE from ESONF SECRETARIAT AND U,S, GOVERN- 

MENT printing OFFICE RESPECTIVELY 
ESONE RECSTR DATE AUG/SEPT 1974 
COMPUTER any 

softrare. type " LANGUAGE 


reader service Ref no 14,5007 

CLASS code " ,501 (CASIO 

TITLE- - • • A CAMaC extended BASIC LANGUAGE 

AUTHOR(S)- • J M SERVENT ( SCHLUMbEHGER ) 

NAME/ACRUNYH " CASIC 

OBTAINABLE FROM" SCMUlMflERGER (SEE LIST OF MANUFACTURERS) 

available UN/AS. DESCRIPTION 

SOFTWARE TYPE" LANGUAGE {FXTENDED BASIC) 


DESCRIPTION" - 

THE MAIN SPECIF ICATIUN OEStRlbtS TmE FACILITIES AVAILABLE IN 

Ike machine independent high level Language laty, appendices 

TU THE SPECIFICATIUN DESCRIBE THE ADDIIIUNAL FEATURES ASSOCI- 
ATED "ITh IMRlEHENTAIIunS, All using GbC ELLIUTT STSIEm lRaTE 
interfaces on The PDP-11, nUva, GEl«40BQ> ANg GEL.2050 
COMPUTERS, 


DESCRIPTION" - 

IML IS A language used TU express THE UREHATIUNS UESlRIBED 

IN The camac haru"ahe specificatiuns, and Their inTemaltiun 
"I lH A CUMPUIER system, Jml STATEMENTS LINK CAMAC STRUCTURES 
AND MOOES UF ORERATIUN TU DATA -STRUCIUMES ANU HEAL"TIh£ ‘ 
FEATURES IN THE COhRuTER STSTEM, 

this DEFINII ION 13 A guide fur Those iHRLtHENTlNG languages 

AND operating SYSTLHS "mU "ISM TO MAKE CAMAC INPUI/UUTRUI 
available TU USERS, FEATURES ARE iNCLUUtU -HICm SUPPuRI THE 
CAHAC BRANCM HtCH"AY AND THE CAHAC SERIAL HIGHWAY, 

The language is defined semantically - the syntax USED TU 
EXPRESS IML depends UN THE ENVIRUNMENT, IME MACRO 
STNTAX IML"Hl IS defined In AN APPENDIX, 


DESCRIPTION" . 

CASIC IS BASED UN BASIL AnU PROVIDES ALL STANUaRU STATEMENTS 
UF BASIC PLUS A SET UF camac RELATED STAIEMENTS, 

CASIC " LIKE BASIC • IS CUNVERSA I lUNAL , Int MUST RECENT 
version LONFURPS TU The IML LANGUAGE (SEE , 5U 1 ( I ML ) ) UtF INED 
HT The ESONE cummittee, 

CASIC IS Implemented on rdp-ii (see ,544), 


OEIGINAB PAGE IS 
OP POOR QUALITY 


Ht*0£» StKVICt 
CLASS coot • 
riTLt- - • » 

A0THUR(S}« • 

PUHL, Stf t » 
NARl/ACHO'^t*' • 
AVAllABLt UN/AS 
UPEHATIVL OATL* 
CORPUTIH • 
INitRpACECS) . 
SOPTRARt type • 

language • 

CAMAC facilities 


reader service 

CLASS CODE . 
TITLE. - • • 


AUTHOR(S). • 
name/acronym • 

available unvas 
operative date. 
CORPUTER • 
INTERFACEISJ • 
min SYSTEN CONFIG 

SUFTNARE type • 
LANGUAGE ■ 


READER service 
CLASS CODE . 
TITLE. ... 
author (S). • 

PUSL, R£F» . 
operative date, 
computer . 
interface (3) . 
SOFTWARE TYPE « 


reader service 
CLASS CODE . 
TITLE. . • - 
name/acronym * 
obtainable FROMM 

SOFTWARE TYPE* 
COMPUTER • . 
INTERFACECS) • 

RAROWARE CUNF IG 


reader SERVICE 

class CUOE . 
TITLE. . . - 
nIme/acrunym - 
obtainable from. 
software type. 
computer . . 

INTERFACECS) . 
hardware CONFIG 


READER SERVICE 
CLASS CODE . 
TITLE. . • - 

NAME/ACRUNYM . 
obtainable FROM. 
SOFTWARE type. 
COMPUTER . - 
INTERFACECS) . 

hardware CONFIG 


XXXVIII 
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. 51 User-Oriented Programs I (full system support) 


REF Nt) 14,SOO0 
.St 

CAMAC OPERATING SYSIIM FOR 
CONTROL APPLICATIUNS 
DR H, MERTENS. IMP. HFA, JUELICH 
CAMAC BULLETIN NO 9. MARCH 1974 
COS 

paper tape. ASCII CUDE 
1972 

PDR'lSf CORE REOUIHEMENTS- IBM 
TYPE 2200 CBORER) 

SYSTEM PROGRAM 

FORTRAN 1 MACRO.ASSERHLER 

SYMBOLIC DEVICE NAMES USfO, SINGLE A 

MULTIPLE action per INSTRUCTION, 

RfAL/UHF DEMEND mANOLINC INCURPUkAIED 


DtSCRtRIION. . 

THE system SOFl.ARt PALAAGE PtHMIth HEAD ANO .RTlE UF uP TO 
100 MODULES, REAL.IIMl TaSaS MAY HE DEFINED UN.LlNt, ABOUT 
60 ELFMENTaNT CUMMAMUS are PRE-DEFINED, sulk as — 

•name HOUULFVCcI, N:2, A«J/UEF1NE SThBULIC NAME 
.READ mUDuLE/FiO 
..RITE module A21/F116 
•OISaB MOUULt/F*24 

.DEFINE TASA/UPEN a T ASa.OEF INI T IUN 
•END/CLOSE TASa-FILE 

•after IB SECS IASa/ESECuTE USER'CEFlNtD TASa 
•IS secs FRUM NO. 

•SULL module SABB/VALUE 1U Bt .RI11EN nEaT To MODULE 


REF NO 14.B009 

,ai 

HACAGROUND.FUREGHUUND SYSTEM pON 
PULSt.HtIGHT ANALYSIS OF TwU. 
dimensional MULTIWIRE PROPORTIONAL 
chamber data 

OR A MEUSLER, IPW, AFA, JOELICM 
BFH 

paper tape, ascii CUDE 
1974T 

POP. IB, CORE PtUUlREMENTS » 2AW 
TYPE 2200 CBOREH) 
magtape, dectape, disk, I 

memory scanning display < in. ROUSE) 

SYSTEM PROGRAM 

FORTRAN t maCRO.ASSEMBLER 


description. . 

THE SYSTEM SUFT.AHt PEMMITS STARI ANU STOP UF BLUCA TRANSFER 
FROM THE A/U CUNVENTERS TO TmE PDF. IB MEMORY CLlST Moot 
OUTPUT UNTO MAGTAPE AIN-LINE SORTING iF OtSHtO), 
the borer INIF.MFACE MAS BEEN hUOIFIEU IU AlLU* BLOCK 
UE'nGTMS up IU 4A IB BIT .(JRDS, 


REF NO I 4, BO 10 
,St 

thiumf control system software 

G, P, GURD, W, A, DAWSON, TRlUMf , 
UNIVERSITY OF ALBERTA, CANADA 
CAMAC bulletin NO S, NOVEMBER 1972 
197i 

4 SUPERNOVAS 
In-house type 

FULL SYSTEM SUPPORT FUR CUNIROL UF 
TRIUMF cyclotron 


description. . 

THE SYSTEM SOFT. ARE PACKAGE MONltURS OYER IDUQ ANALUGuE 
parameters and 1000 OIGITAU STATUS PUInTS, SEARCHES UUI.UF» 
LIMIT READINGS, DISPLAYS MEASUHEMENTS UN MtOUtST, 

SETS OVEN 300 ANALOGUE POINTS FROM A CENTRAL CONSOLE ANO 
PERFORMS A number UF OTHER HOUTiNtS, 

A real-time EKECUTIYE PRUGFiAh . NATS (FUR NOVA ASYNCHRUNUUS 
tasking SUPERVISOR) • schedules AND SUPERVISES CAMAC TaSkS, 
SUPPORTED BT A SUBPRUGHAH gibRARY, AS THEY ARE REUUtSTED, 
JOBS TO BE PERFORMED ARE STRUCTURED INtU SEUuEnCES UF CAhAC 
UPERaTJUNS specific to A PIECE UF nA«D.AhE (• GAMAL MUDDLE), 
there is thus a direct HUDULAR HARu.ARE.SUFT.ANE CURMESPUNU. 
ENCE, CUNTHUL is BASICaLLT cluck. initiated SUFTwaRE sUn up 
cyclotron F.UNIIUM1NC, BUT INTERRUPTS ARE INCLUDED, M4lN(.r 
initiated HT CUNSULE, 


REF NO 14, son DESCRIPTION. - 

,si THE program UCLUPItS 2 k UF REMURT AND USES A DATA AREA UP 4K 

BASIC SINGLE PARAHETEH MCA SYSTEM (MISP) FOR UP TU 4096 CHANNELS ACUUISlTlUN, 

NlSP THE package CONSISTS UF A UISPLAT DRIVEN. A USeR UMIENTEU 

NUCLEAR ENTERPRISES (SEE iNDEK UF HFRS) TELETYPE HANDLER. ACUUISlTlUN CONTROL. ANO A DATA MANIMuLA. 
SYSTEM software TIUN ROUTINE, 

PDP.lt, BK MEMORY t REAL TIME CLUCK THE DISPLAY DRIVER IS HUN AS A BACkGhUUNU TASK .MlLH IS 

9010 (NUCL. ENTERPfi) INTERRUPTED BY THE ADC, CLUCkS AND ItLETTPt, 

(PROGRAMMED TRANSFERS ( INTERRUPT ONLY) THIS PACKAGE C*N bt OBTAINED WIIH muLTISCALER OPTION, IHt 
ADC (LAHEN OR 9060), 9021 LIVE TIME HTC, hahDhAHE IS EkTENDEO -ITh A 9003 OH U03 SCaLeR, DATA AREA IS 

TTY/REAOER (7064),TEK603/604 OR LANSCUPt DlVlOfD INTO 4 AREAS, EACH UNt ThUUSAND LF(ANNtGS, 


ref no 14,5012 OtSCRlPTIUN. 

,bl T"t PRUCRA" UCLUPItS 6 M LEAVING tOK UF MtRURT FUR UAlA ALUoI- 

O'JAL mCA system (DAmCAS) 5IT10N (4K .OF 16 BITS 4 4. UF 24 BITS), 

oahcas The software package CONSISTS UP A display dmIvek, a teletype 

NUCLEAR enterprises (SEE INOEK OP RFKS) HANDLER FOR UPEHAtuR tONIRUL UF DATA AtUUISITJUN, DATA MANlW 
system SOFTWARE ‘ PULAT TON RUu I I NE , AND A MUUTINE PUR AUTUNUMUUS CONTROL OF 

PDP.U, 16K MfMURY t HEAL time CLUCK DATA ACUUlSiTlUN AnO MAG Tape TRANSFERS, 

9030 S 9033 (NUCLEnTERPH) 

(PROgRAMHEO s AUTunu"(IUS TRANSFERS)' 

ADC (LaBEn UH 9060), 9021 LIVE TIME RTC, 

TTT/READER (7064). PUNCH (7065), MAGTAPE 
CCS 0042) , TFWb03/b04 OH LANSCUPt 


REF NU I4,b0l3 . UtSCRlPTIUN. . 

,61 IhE SYSTEM IS LAPAbLt UF ALCtPIlNG FIVE PAHAHtItK EVENTS ANO 

MULTI parameter Data ACDUISITHJN system STUHING I ME" UN M*G TAPE, SiMULIANtUuSLT PERFUWMING multi* 
MUOAS I channel ANALYSIS UN UNt SELELTEO PARAMETER, 

NUCLFAH ENTERPRISES (SEE INDEK OF MFRS) wINOd.S MAY Bt SET UN EACn PARAFitltR FUR BUIM MUDES, TuGETHEH 
SYSTFM software ■ wlTM A COUNT DIVISION FACTOR SET UVEh IHt REGIUN UP INIEHLST, 

PDP*ti, BK MEMORY A Real TTm£ clock data dumped in list mode Hay Bt hEAD BAC. PUm analysis; 

9030 (NUCL, ENTERPH) 

(PROGRAMMED TRANSFERS t INTERRUPT ONLY) 

ADC'S (LABEN OH 9060) B CVUNC SFLECTaR ; 

CCS 0049), 9021 LIVE TIMEH RTC. TTY & 
mag tape, TEK 603/604, 


1-4 



■ u«»tct 

Ck*»s CUDt . 
4UTNtl)<(t)* - 

l1»'tX4t|t( 04Tk« 
SU4T04MI TTPl • 


■1401P tLNVICt 
CLASS CUOl • 
TITlI- • - • 
••AMt /4CNU««> • 
«4i>irt*i4>iCt S’* 
OmTaILaBLI *mum 

nPCNATIVl U4U. 
CO-XOTIP . 
INTLP»4Cf(S) • 
suA'xAHt r«pt . 


HtAOtP S(M«ICI 
CLASS CUOi • 
TITLC- . • . 

•<4M| /aC**U*>Tm • 
nSIAIAASLt APU»» 
S0AT«4PI 1»Pl* 
CUMPuTt* • • 
ixTepAACKs) • 


H(40tP StxvICC 
CLASS coot • 
tlTtt- • • • 
AUThUR(S)> • 
RUSL, Ptf, • 


N4»t /ACSUN'* • 
HAIkTINANCt Hf« 
OSTAlLASLf AROm 
AVAUABlC un/as 

ORlHATlyt 04U. 

CO«*RUtlR • 
INTIMP4CC(S) • 

"lAi S»S»l" COXA lu 
SOAT>4Ht tVPI - 
LAXCUASS • 
must LAXSUAGI • 
CamaC aaCIlITUS 

AACILtTltS . 


PlAOCP S(N«ICl 
CLASS coot • 
TItu- • • • 

aUThum(S)« • 

RUBL , RCA , . 
XAHt/ACRUXTK • 
OBTAlXAHLt ARUM 
AVAIkABtt UX/AS 
riPlRATJVl OATt> 
rOMPUUR • 
IxTiraaCKS) . 
SUATmaRI TYPI . 
tAXSUACE • 

CAMAC AAClLlTltS 


hEadSm StMvlCI 
CLASS CUDl > 

title- • • • 
auTmOR(S)- • 

XAMt/ACROXYM • 

vtRSinx. - . 
(IBTaIXABLE ANU- 
available UX/aS 

nPfRATJyf OaTE- 
CUmRuTER . 
IXTERAaCE(S) * 
boat-are tTPt • 
lAXCUACr • 
jnCURP TECmxIluE 
Ca-aC AACUniES 


I I ‘ 
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REA SU I4,B0|A 

• S I 

0 6oR0( txIump,ux|v, alpEmTa.caxaoa ' 

CA-At 

t«T I 

STST|h SuAT-aRE 


III SChiPTIUx- . 

T-E SYSTEM »1 >AI-a«a- CamaC • luxSlsTp uA SEYLMAl SWBMUwTiXi 
CALLS, These a«e- • 

PRIMITIVE SunRuuTIXES Rt-Au--1XL T-t ALTUAl 1 /U uPEMATIUXS, 
muUULC SwRMuwTiXiS, t-E mua/aOL SURRuuIIxeSa CamaC lamp 
IxTehRuPTS, serial TaSaS, anu ax IxTeRpReIER (AOm UAIAI, 


. 52 User-Oriented Programs II (specific run-time programs) 


REA XO lA.BOIS 

UPERaTIxc system S'JAT-are PaCaaLES 

SEE OESCRIPTIUX 

DEC 

DEC (SEE IXPEA UA maxuA aCTu-ERS) 
I9AS 

PCP-U 

SEE DESlRtPTlUX 

CAMAC SERVICE Routines, user-, 
IxTeRAaCF- e descriptor PhOLRAmS 


DESCrIR'Iux. . 

TmE boat-are RAI*auES are CUMPlETE upERAIIXI, STSTEmS, 
CUXIuulLERS ANU uRERAT|nL systems ame -ElAIEu as AuLLU-S-- 
CA-II-C USES RSI-II-U UPERaTIXw System 

CA-tl-E USES RSa-II-m ux RI-II 

CA-II-A uses RSA-II-m um Rl-tl 


REA XU lA.BOtB 
,S2 

CASPaC - A SOAT-are PACaALE Aum CUMMUXI- 
CATlox -ITm CAmaC-PhUCESS-peRIP-EralS 
CaSPaC 

IDAS (SEE IXOEA UA -AXUA ACTuRERS) 

system UA Re-EXTHaxT assembler routines 
ROR-11 (DEC), m|n 740 -OROS OA -EmoRy 
I CR-II (SCmlumbERCER) 


UESLr|PT10x- • 

Tme SyS'E- uA assembler routines allUR CUMMUXlLAI lux -It- 
Camac-PRUCESS — ErIrmERAlS uSIXU SIxulE--uUU IRaxsAem ROUE AS 
-ELL AS SLUCa I-assAeR muDe UX AuhTRAx and ASSEMBLER LEVEL, 
interrupt aCTIuXS lax be UBTaIxeU |x TmE AuRm uA ax ARbIIRARy 
SEUUEXCE UA LARAC (RAXSAEMS UX AuNTRAX LEVEL, 

XU SOAT-are uPERaTIXL Sts«EM IS xEEUEO, AXU CApPAL CAN 
T-ereauRE be uSEU auIUXumOuSly as rElL as |x CuxxeLTIUx r|Im 
A real iire UR ba'tlm uperaiixl System, 


.53 User-Oriented Programs III (subprograms, etc.) 


REA XU 14,9017 
,9J (BASIC) 

CAMAC AND IxTERACTIxC prquRar-IxG 
OR I - R|MH(R, CCRX, LEXEVA 

PROC CAMAC STMPUS, LU>MBS, UEC l«AJ 
A BASIC callable routines, 

XP CROUP NOTE, xP-omC, CERX 
"PC"A, mpcmb, mpcmC 
OR E H PI-MER 

XP 0|V, CERX, CM-lJlt CCXEVA 

PAPER tape, ascii Code 
I9AI/72 

M-P 2100-SERIES, BA 16 BIT -URU8 
220KBOMER), T2<B I mPCC-066(CERX) 
TTY QM IE- 4010 terminal a lC-41 
SET UA Subroutines 
MP assembly 

BASIC (XP EaTEXSIUN UA ) 

IX-LIXC CODED CALLS |X BASIL, 
SUBBUUTIXiS |X assembly, abb AOUR 
bixcle t rultiple altiox per 
IxSTRUCTIDX, no demand RAXOLlxC 


DEBCR|PT|UX- • 

TrEBE BABICrCalLaBLE Ca«aC SuBROuT|xe1 |x Im-ee YErSIUXS AuH 
TmhEE IxTERAaCEI PrUyIuE "uBT LUmmaxu aalIlKIES AuR CoxTnul 
AND DATA ThaxBAER, data -uRDB "AY BE iS OR i* BITS LUxC ' 
(only 16 SITS AUR mPlLr066), BIxant, BCD UR LUUlC (0 UR I), 
hUuTIxES CUyEB BLOLa T-axsaErS, pruCRAmmlo axU SEWuExT|al 
AUORESSIXC A UAILIIY RUUTIXES, |x TUIAL IS S i UPIIUxalLT, 
btxERAL AURR UA call statement-- 

• • -call (SuBRUuTIXE Xu-bem,C,X,4,A ,U,u> 

• • -CALL (SUBRUUTIXE NUMBER ,C , X, A ,7 ,U( I ) , u , - ) 

RMERE* R 11 RUHU CUUXI, 0 IB UATA, C,X,A,A, A U maYE USUAL 
REAXIXC 

EA-- C4LL(IB>I,2,0,I6,U(1),U,20) 

time is 4PPM 9 msels/statemext, bluc* imaxseer Call u|xe- 
RATED directly by IxTErAaCE aBE mucm EASIER, 


BE* XU I4,90|B 
,9S(EURtHAX) 

SPECIE ICaTIUXS AUR standard CamaC 

subroutines 

BICmaRO E Thomas JB, 

CAMAC bulletin xU 6, maRCm I07J 
SEE OESIRIPTIUX 

USAEC xlH CUhm|tTEE, CamaC SrC 

ALtUBltMM 

1973 

IXOtPlXUlXt, H£MOHY SUE NOT SPEC, 

ANY 

SET t)E SuBHUUTIxtS 
EURTRAX 

AuxoaREXTaL CamaC UPERaTIUXS, staxoanc 
BLOCR THaXSEEBS In SIxclI S mjlT|PlE 
ACTION statements 


UESIR|PT|UX- • 

A SET (IE 6 SuBmuuTIXES, UA -M|Cn UXE IS LalLEU BT ALL ImE 
UT-EP PERMITS A UREAI yarUTt uE SIXULE axw MULTIPLE C*maC 
UPEmaTIOxS Tu be pemEummad, uEmaxu maxulIxu, UTmcm Tmax by 
test L**> I* XUT CUYEMtU, 

Tme Subroutines eaelute camac uperatiuxs as aullums-- 
CMCBSC • single lAMAL Auxc’lux At single auOrESS 
ONE OR RU*E M"ES 

(MCSIU • single LAmal AUXCTIux at SULCtSSIUX UA ADUMiSSES 

C"CASC • SPECIAIED camac AuxlTIOx IX auUmESS Scan muuE 

C»CRPT . SRECIAItO Camac AuxtUUX ix RtPEAl muuE 

CMCSTP • SPICIAIEU CamaL AuxlHUX IX SlUP MUUE 

CMCLUP • SPEllAIlD C*"4C EuXCTlUX aT a RIEhamCmUal SEuUtXLE 

(IT addresses -ITh uPtlUXAL S-IP uE SEUutxCt BASED UX u, 

GEXEmal AURR UA STATtMtxT-- 

call CMC,,, (PARARtTtP LIST) 

EIARPlE-- call CmCSTp (A ,B,C,X,AU,LX,OATA,tRRURA,Xt>| 


PEA MI T4,90|9 
,93(EORTbax) 

FORTBaX subroutines 
M PUML 

auBTBax calls 
Y002 

" pUml, eel, «Aa, JuELICm 

DECTiPE 

»4RC» 1972 

PDP-11, 16« 16 BIT -iiRuS "E“ORY 
type 1S33a (bURER) 

PRUCTDuRE CALLS 

ALIBTPAX (IN POP. 11 (l-RtAOTO COUE) 
tX-L|NE SUHRQuTIXt LALLS 
S|XGL( 4CT|(IX STATl-tNTB 


DESlRIPTIUX- - 

AURTRax SUBRUU'IXES AU- SIxGlE aLTIUxS, RuCm 6|hPlEr Than 
Tme XIm APPmuALm (mEA , M, E, TnuMAS) AuN Tme BUMER I633a 
luxiholler --iitex |x -e-exTraxt Cube, 
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RtAptR SfcHVICE 
CLASS COOL • 

title* - " • 

AUTHURtS)* • 
RAMt/ACRUNYH • 
VERSION* • - 
HAINTtNANCE BY* 

hbtainable erom 
available ON/AS 

OPERATIVE OATt- 
COMPUTfH • 
INrEHEACE(S) - 
SOFTWARE TYPE • 
LANGUAGE • 

RUST language * 
INCORP tecrnioue 
camac facilities 


ref no IA.S020 
,5J 

CARAC function fur will 

L Byars, h aeyslh 

CAMAC, carint 

RTll 

ORTEC 

owftc (See inula of ranufaciuhers) 
PAPER tape 

19/A 

POP-11 

OCOll (tGSt/OHTEC) 

SUBROUTINES 
PDP*n assembly 
RT ll/fORTMAN 

CALLS TU FORTRAN LIBRARY RUUllNtS 

single or multiple instructions, 
dehano handling 


reader service ref no U.S071 

CLASS coot • .sscfohtranj 

AOTHQR(S)- . J M STEPHENSON, LA ALAISNEH 

nAHE/ACRCnYM . F5CLIH 

obtainable from kinetic SYSTEMS (SEE INOtA UF MFRS) 

operative UATL* 19/A 

COMPUTER w ^ POP-U, 16K CORE Mt«DRY RtOUlHED 

INTERFACE(S) . TYPES S9 H A , 3991 i 3992 (KINETIC) 

language •' fortran 

SOFTWARE type • library OF FORTRAN FUNCTlUNb AND 

subroutines 


UESCRIPTIUN* - 

TMIS SOMwane PACKAbt ti'NSISTS UF A NUMBER UF SouRUuliNta 
FUH FORTKAN/RTll CALLING Cah»c FunlUUNS, 

THE CAFiaL call SIAIEMFNl MAS ImE Fullu-Ing Fumm-- 
CALL CAMAL (IF, In, 1A, 1G, iuaTa) 

They are uStu lu Transfer uaia tu/fror la«ac and Flr teSi 
PURPUSES, 

IF, In, IA are RESPELTIyELY FuNCUUN, STAIJun AugRESS anu 
SUBADDRESS, lu IS noth utill and xgiI, 

CAmInt is used Tij mangle InTEKrupIS fru« C»maL LRAIE, kng 

MAS THE general FliRM-- 
CAMINI(lN,NAHtl) 

"HERE IN is- THE SIATION Number AnU NiREl lb iHt name UF iMt 
suaRUgTiNE lu Bt EAttuitu -men The InTerrupi ulcurs, 


UESCRIPTIUN*. 

IMIS SOFT. ARE PACK4GE IP.PLthtNlS TmE CmCbSL SEkIES uF SUNU* 
ARU FORTRAN LALLS UtSCRlBEU IN CAMAC HULLLIIN NO 6, 19/3, 

IT also Includes tme bit ranipolai iun funciions t*u,usivt 
I'R, inclusive or, anu, Not, & shift, Iml p»LKaGE SUPPuRIS 
UP TU 8 crates InIERFalEO ImrOuGm rUuEL 391 1A unIbuS •) 
crate CONTRULLEMS, up TU / CRATES PER JV91 BRANCH URlVtR ANU 
Up To 61 CRATES PER 3992 SERIAC BRANCH DRIVER, The NUMBER 
OF PARALLU ANU SERIAL BRANCHES SHUULU BE LESS THAN B, 

• ) UNIBUS, lb A TRauE Mara uF digital EuolPHtM CURP , 


reader service ref no I4,b022 

CLASS CODE • ,‘33 

TITLE. - * * I/O macros for CAHAC 

AUTMQR(S). « D stuckenbrock, G KLENERT, 

SIEMENS AG, KARLSKUME 
NAHE/ACRONYH . MACAM 

obtainable from siemens (SEF INDEX UF MFRS ) 

available ON/AS paper tape, cards * SUuRCt DECK 

operative date. NOVEMBER 1974 

COFIPUTER • . PR 320/330 

INTEHFACEtS) • CC 320 K SC 330 (SIEMENS) 

MIN MEMORY SPACE ,SK . lA UE 16 BITS (SUPERVISOR txCL) 

depending on hardware 

MIN system CONFIG TTY AND SUPERVISUR PHUCHAM 

software Type . i/o routines, lam handling 

FNVIRUNMENI for . CAHtC SUFTmARE IS ASSthBLEH 300 

LANGUAGE « macros ■ ASSEHBlEH, calls - FURTHAN 

FACILITIES . concurrent MULTl.uSt“ UPERAIION, SYSTEM 

RUNS UNDER RFAL.TIHE SUPERVISOR 


READER SERVICE 
CLASS coot 
TITLE- . . - 
AUTMUR(S). - 
NAmE/ACRUNYH • 

obtainable from, 
available UN/AS. 
OPERATIVE Date * 
COMPUTER . . 

MIN memory space 

INTEHFACtCS) » 

software type* 

MlN SYSTEM CONFIG 
INCORP TECHNIUUt 
CAMAC FACILITIES 


ref no 14,6023 
,63 (BASIC) 

BASIC * subroutines 

0 STUCKENBROCK, SIEMENS AG, KaHlSHUhE 
BASIC - CALLS 

siemens (SEE INDEX llF MANUFACTURERS) 
PAPER TAPE, CARDS 
1973 
PR 320 

IK OF 16 BITS (BASIL COMPILER EXCLUDED) 

CC 320 

SUBROUTINES 

TTY AND Basic CUmPUFK 

EMStOOLU BASIC CALLS TU SUHKOUTlNtS 

LAM haNOLINC 


UtSLHIPTIUN. - . 

A SET OF I/U MACRU SuBRuuHneS Can be LAlLEU BY ant uSeR 
program cOnLURHEMLY Running UN IhE LUMPdIER, PRuVIUED they 
UPEHaTE under a real-time SUPERVISuH PwuGRAM, the RUUUNtb 
CUMPRISt TME FUNLTIUNS head, .hIIE, AND tXECuUUN uF CunImuL 
commands, HLUCk transfers are PEWFURhEG UN CuNblANl UR 
variable C*mac ADDwEbS, and IN INCREMENT mode UK WANUU".Llb.I 
mode, tme CUURUINAIIUN UF USER PWUGRAMb ANU LAMAC PRUVIOEO 
BY THE SUPERVISUk, FACILITAIES GREaTLY ThE LAM HANDLING, 
the SYSTEM ALLU»5 uP TU B bRANLmES, EALm rITm / LRaTES, 
SYSTEM SOFTWARE environments FAClUIAIt INIOHPUKATION UF 
The SUBROUTINE CALLS AS STATEMENTS EHBtUGEU IN FORTRAN 
PRUGRAHS, 


OtbCRIPTlUN. . 

Tme subroutines in ASSEMbLEM AwE handled BT IME BASIL.UN-320 
CUhPjlfR (iNlFwPREItw?), 

The statemem - • 

call (CM, PARAMEtER LIST) 

CAUSED PRUGwAM TU JUMP lu SUBRUUUnE CALLEU, 

T"E FOLLU-InG LAhic oPEwaIIUNS C«N BE tXtCUIEU * " 

* single OPERAilUN (READ, .RITE, CUNlRuL) 

* interrupt REGISTrATIUN and Jump to lam handling rUUIINE 

* WAITING FuR lam 

'Parameter lisi' is a string of cmaralieks spelipying ihe 

OPERATION TU HE EXECUTED, 

example • - 

CALL(Cm.nAF, 11, 0,0,41) 

* "MEHF il,U,0, S station, SUMADDMLSS jFUNLtiuN, XI = variable 


READER service REF NO 14,6024 

CL4SS CODE . ,63 

TITLE- - « - T-U-LEVEL CAHAC PERIPmEHAL HANDIER 

AUTHOR(S)- - L M TAFF, UnIV UF GpOnInGEn, NtTMtRL»NDS 

puBL, REF, * Computer physics cummumcatuins 

* (TU BE PUbLIShtD) 

MAINTENANCE BY AUTHOR 

obtainable from* author 

available on/as* OECTAPt (ASCII CODE) 

OPERATIVE date . 1974 

COMPUTER « • OtC PDP-11, MIN 8K UF MEhuRY • 

INTERFACt(S) * CA-15 (UFO 

operating system (SUFT»AR£) • dec mJNITuR system (ApSS) 

SUFTwaRF TYPE- CAMAC OHIVEH/LAM hANOLF-R SlJiiRUuT InE , 

I/O DEVICE handlers, CMCBSC SUhRUUTINL 

language - - assembler ■ 

host language- Any supported By system 

INCORP TtCHNIOuE UNKFO AT LOAD TIME 

CamaC FACILIIItS single CAMAC UPFRATIXJNS, DAlA CHANNEL 
transfers, DEMAND handling, RE-ENIRant 

REAOtH SERVICE REF NU 14,5025 

CL4SS CODE - ,63 

title- « - « camac/furtran V Interface sufi-are 

AUTMOR(S)- - A GSPu'NNtH, SEN ELELTRONIUlJt 

MAINTENANCt BY SEN 

available UN/ASW DISK (ROnS), full RUUS compatibility 

OPERATIVE date • MAY 1976 

computer - - ANY NOVA (-ITh-IThijuT FLOATING POIM ) 

INTERFACED) - CC a023 (SEN) 

SUFTmAHE type- post pbucfssor 


DESCRIPTION- . 

the CAMAC DrIVER/LAh handler IS A gLubaLLT LINnEU SubPUUIlNL 
Fur ExECuTItG single CAMiC, upErA t IONS , luNlRULLlNG ACCESS TO 2 
hARO-aRE data lhaNNElS via UdFuES, and GIVING LUMmul 10 The 
PROPER USER routine -MEN A LAM uLCuRS, JT MAY BE LALLeD BY 
assembler LUDEU'USER PROGRAMS, T"UHAS' SlANDAWp SUBROUIlNt 
CMCBSC (HENCE all UThEr of h|SmugIInES -hICh L*LL CMCaSL) 

•SEE ,S3 ahijyE - and I/u handlers fur CAMAL IMEwFaCEO 
pekipmerals, either from haINSTREAH uR LAM hardware mriurUy, 
CAMAC INT erf Act O DEV ICES FuR -mIL" HANDLERS LURHENI LT EXIST 

INCLUDE A line Printer, card reader, InckEmemal pluiter, and 
A IEkTRUNIx 4010 terminal, FOR GEVILL HANDLERS, t*MAC IS 
IRanspirEnt, 

IT is RELATIVELY FAST lu ADARt A handler FUR an I/u BUS DEvILE 
lU LaMaC SIMPLY nv SoBSTIIdTIng SuoRuuUnE L*LLS TU IHe OrIve- 
F'JW 1/0 uPtwATlUNS AND UoSERvInG A Ft- NdN-RES I R 1C 1 1 vt CunvEn- 
TIUNS, IMIS' T-U-LtVtL approach LAN ACLU'UDAIE CAMAC LANGUAC>tb 
IF ACTION STATEMENIS Are CuMmIlEU INlU S/JBrUU T INt C ALLS J 


CESCRIPTICN- • 


XL 
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. 54 Support Software I (translators) 

KtADtH SLHVICt l4,!)0'c;6 ^ bLr T - 


CL»SS Ctmt • ,!j<1 

TITte- - • - 3/U<vlP AN uijtVt*<S*L PkuCISSi.n 

AUTHUH(S)- • SOFT.AHfc«PANTNtwS 

MAlNTEAlANCt nY« SUFroAHt.PANTNtHS 

UBTAlNABLt FHUM SAM£, (StE INDEX UF maMjFAC I UHLKS ) 
IlPtKATlVt UATt. APPIL 1974 

SOFTnARt IVPL . M»cwn PNOCtSSUW 

LANGUACF - WRITTEN IN "IliN LtVLU UANGuAGt 

COMPUTER - CAN RUN UN ln>', UMVAO CUC>ICti 

SIEMENS, ETC, 

CAMAC facilities INCUHPIIKATED IN.UINL H-IR AULL-StT 

IMU „iTm macro PRi CtSS'.iR vIHFCUvtS 


READER SERVICE REF VtJ 14,5077 

CLASS coot . ,541 

TITLEr . • . A macro ASStMBLtR FoR TYPE MBO*ll 

mICHOPRUUPAmmLO 5KA.\Cn U«lVt- 
CUmRUTER • PDP-11 

OHTAlNABtt from hi «A SYSTtl'S (SEE iNl'tA uF “FHbJ 

SUFT-ARE type - macro ASSEMbcER C I R ANSI, A TOR ) 

INTERFACE(S) • MBO-ir (HI RA STSIEms) 


reader service ref no 14,5020 

CLASS CODE • ,54UMACRaU) 

TITLE- • - - MACROS FOR 15SJA r 

author CS l- - MR, kEEH 

NAME/ACRONTM m macro I533A 

maintenance by- MR, MtuR 

obtainable from MR, heEH, EtL, RFa, JuelICh 

AVAILABLE UN/AS OECtAPE 

OPERATIVE date- FESRUART 197J 

COMPUTER - PfP-ll, MI" BF 16 ail -ONUS 

INTERFACEtSJ - TYPE I5J3A (BORER) 

MIN SYSTEM CONFIG DOS VOOA, 00«» 009 

SOFTRARt type • maCRU-SE T 

LANGUAGE • MACHO II 

CAMAC FEATURES- ARE INCURPURATED 1N-lINE 

environment for « CAMAC suft-are IS assembler 
CAMAC facilities single action statements, 
symbolic DEVICE NAMES 


READER SERVICE REF NO 14,5029 

CLASS coot . ,54l(IML) 

TITLE- - • - MACRO-IML IHPLEMEnTaTIUNS Fum dec 

PDP-11 COMPUTERS 

authcir(s)- • M xubiti# r kind, hmi-behlin 

PUBL, REF, - CAMAC BULLETIN NO 12, APRIL 19F5 

obtainable FRUM M KUBITZ, BEREICM 0/E, MMI. BERLIN 

GERMANY 

available un/as all media 

OPERATIVE DATE. 197A 

COMPUTER - PDP-11, 16K, 24K, 44K, UR 52K 

INTERFACY-CS) - CA-llA COtC), 153J4 (MUHEN) 

HIN SYSTEM CONFIG DOS VCB709, RSX-llO, RSX-llM 
SDATmaRE type • macro SET OF IML (ImPLEMenIEO) 
language - PDP-11 assembly 

CAMAc features- incorporated by macros 

CAMAC facilities full set of Iml-maCRDS 

INCLUDING demand mANOLINC 


reader SERVICE ref NU IA,50.J0 

CLASS COOL . ,543(CATY) 

title- • • - A CamaC testing aid for use UN POP-U 

AUTmURCS)- - F R GOLDING, APPLIED CUMPUTEH STST, 

NAMt/AC«ONTM - CAlll 

UBTaINABLE from applied COMPUTER systems LTU, 

R£NZEL ELEKTROnIK, NUCL ENTERPRISES, 
(SEf INDEX OF MANUFACTURERS) 
operative date- 1973 

COMPUTER • POP-11, AK UR 8K memory REUUIHED 

depending On version 

INTERFACECS) • C-CSC-U (RENZEL), 9030 (N,E,) 

MIN system CONFIG CONTROL VISTA, READER, PUNCH 
SOFIrARE TYPE - SYSTEM (EXECUTIVE, COMPILER ETC) 
LANGUAGE - CATV CBASEDOn HASIC) 


reader SERVICE REF NO lA,503I 

CLASS CODE - ,5A3(CAry) 

TITLE- - - - A CAMAC TESTING AID - CATV • fuR PDP-11 

AUTMOR(S)- - F R GOLDING, R F CMANflFLD 

obtainable from- GEC ELLIOTT (SEE INDEX OF m»NuF ACIUREHS) 

OPERATIVE DATE • 1974 

computer • • PPP-U, mJn 4K REUUlRtO 

mIn mErORt SPACE 

INTERFACHS) • PtI-llC/0, IVG-ll (GEC ELLIUTT) 

MIN SYSTEM C'JNFlC CONTROL TTY OR VIST*, kEADEM, PuNC" 

language - - CAIV (BASED ON BASIC) 


a/uMH ia * U**DUAUL i'vut • »,/ 

TmcrefiiRE a ruuL Fur -acmu tJp4NSiv<s uf cytM’ t«isu’.v u" 
ii» Future p«uG-ammiNo language, i-'os s7unip MiiMii'iS fnd 
PRt'CESSES MACRub IN MIG" lEVEl LANjpAGlS IruR’RAN, bibiC, 
ALGOL, pearl, tTC,) AS "ELL *b AbbLM»w< LANGuiutb, S/-N1P 
I'PEHATES AS * P“L-RRuCtSblH uEnEraIInG buuRCt tuDE 
SIAH-tNTS FUR SubbtGoENT CUmPIlAIIuN, PUbbltiLY uN »ND!ntR 
CO-PuTtR, 


i tbCRIPI Kin- . 

’“t "4CR'.‘ AubF-nut" MAS 'lEtN DLYt-uPt^’ Tr FAClciTt't T -E 
-"lUNO OF PRjGRAMb FuR IHt "bU-ll “ I C R /P"uC t bbUR "1 Lr F At L , 
'"h ASSEmBLur IRAnSLATES PRUGRA“b -RlllEN IN maCRU CuDt INtu 
iNb I rijCTILnS ALCtPTAbLt bT IrE “oU-M, gP To 4K InSIRuCI- 
l^NS CAN bE bTORtu IN 'RE ■'Bg-11, a F,,nCIKin uF mErjRy SIZE 
r-lLH GO FROM 250 'O 4« -JRiJb IN INCREMENTS O' 256 am,, !«•, 
InS'RoCTKNS are RICRO-bIPuCIuRLo Forming A PU-ERFot St', 


^aSLRIPTILN- • 

'•'IS Ib A simple macro SET (No otCt*"* ' luNb ) FuR SINGLE 
action statements, tXECoIIUN bPctu IS rigrE» (APP»yA Ju 
MlCROStCb PER INSTruCTIUn, DEFt’-DlNG UN I YpE U‘ InSTruCTIu’. 
1 N 'VPE uF PUP-IU, M-I InTERPl-f t Able -ACros (PRIoRH'i/) 


description. . 

IML IS IMPLEMEMED UN POH-U IN AtCUMUANLt -IIm IHt MALRo 
SYNTAX AS defined in TrE OuCuMEM ESUNtZlML/Ol {StE CLASS 
,501 ABOVE), VERSIONS ARE AVAILABLE FuR InIeRFACE- 
COnIHULLERS and dec UPEKaUNG systems as mentioned In IME 
lef r column, 

ImpUEMENIAIIUN uyvERS THE FULL SET UF IML malRuS AnU ULManU 
MANULING ExCtPI bLUCx transfer On SPECIAL LAM, X-ERRuR 
CUNTROL statements, and SUBSLRIPI mUDE, TrANSEER modes NU't 
implemented by RAHUrAHE are SImuLAiEu by SuFI-ARE, 

I/O transfer instructions are EMbtDDED in I ME MACHuS AND A-t 
PERFORMED DIRECTLY IN ALTlUN BY THE mACRoS, 

ADDRESS calculation AT ASSEMBLY TI«E GIVES UPTl"lZt0 
address CALtuLATIuN AT ASSEMBLY TIRE GIVES OPTIMUM RUN ri«t 
CODE, MUST LANGUAGES can be PDP-11 mACRu ASSEMBLER oR 
FORTRAN (VIA SUBROUTINE CALL), 

“EMURV HEUUIREMEnTS VARY rITM OPERATING SYSTEM AND IF FULL 
SET IS NEEDED, UK A SUB-SEl IS ALCEPIABLL, 16K IS RERUIrEC 
FUR A SUB. SET »1Tm UuSVOB/09 iJR rSX-HM AND 52K FUR FULL SET 
AND HSX.llD, 


oescri.piion- • 

USERS TEST PRUGRAmS ARE TYPED iN and TmErEaF 1 E- CUMPlLtD AND 
RUN, IT IS possible TU edit TmE PROGRAM »n 0 RERUN ll RlIH- 
UUT having TU RETYPE TmE ORIGINAL PRuGram, CAHac CUMhanuS 
ARE t“H£DDEU IN PRUGhaH AS STAIEMEnT LINES., 

CAT M MAS INTEHRuPT AS SYSTEM FEATuRl, TmE OSEh may TYPE MIS 
o«N interrupt routine, 

Tm£ CaTU titCuTlVt program CHANGES SLIGMICY RUM INIERFACt 
USED, HUT ALL routines ArE IDENTICAL, 

VLRSIONS OF iMlS system IS alSo avxIlAblE froM GEC EllIUIT 
(SEE FOLLO-INC ENTRIES) 


utSCRIPT lUN- - 
SEE PRECEEDlNo *: • - < 


ORIGINAD PAGE IS 
OF POOR QUALrryi 


1-7 XU 



CAMAC SOFTWARE PRODUCTS GUIDE 


BfAOtW StWVJCt 
CLASS cont - 
HTLt- - . 

iUTHUH(S)» • 
IIBTAINAHLt fROK. 
tlRLHATIVE UATt - 
CUHRUIEH - • 
INTfHfAce(S) . 

SYSTEM CO^^ IC 
LA»JC.i;ii;t " • 


Rt» M(> U,b032 
.bAJCCAtV) 

A CAM*e TfSTiNt, »ii) - CAIY • fllR nUYA 
R R Ct'LL'ISG, R F CRANFIELU 
crc ELLlClTt 
MANLw 1V7S 

NOVA SfcRILS CIIAIA KtNtXALJ, ''I'y 4 K 

NUVA EYecurivL Sujrt (c.tc llliotu 
ccintruu tty (,iR viju» RfActR, Punch 

CATy (BAStI) IJN BASIL) 


OISCRIPTION- - . 

(SLt CLASS .bOlCLAIYJ am, HNtCttl/IMi tNtnitS tUASS ,bAJ) 


RfADiR SEWVrct 

CLASS CUDt • 
TITLE- - 
obtainable FHUM- 
CUHPUTER • - 
INttRFACt(S) - 
LANGUAGE • • 


RE> Ml 1A.50JJ 
,b4J(CATy) 

A CAMAC TESTING All) - CAIY • fU« ThE 

GtC ELLIUTT 

2050 AND 4080 (GtC) 

tXECUTl»t SUITE PllR 2060/4080 (GtC) 

CAIY (BAStI) UN BASIL) 


GtSLWIPTION- - 

(Stt CLASS .bOKCAlY) ANU PWECttulNG tNTHItS CLASS ,840) 


HEADER SERVICE 
CLASS coot - 
TITLE- - - - 
AUTMUH(S)- • 

PUBL, HEF, • 

NAHt/ACHONYH • 

haintenance by- 
obtainable from 
available un/as 

OPERATIVE DATt- 
COMPuTtR • 
INTERFACE (S) • 

MIN SYSTEM CONFIG 
SOFThaRE TYPE • 
LANCUAGF • 

INCUHP TECHNIUUE 
ENVIRaNMENt FUR « 
CAMAC FACILITIES 


REF NU 14,6034 
643 

A BASIC MACRfl-ll compiler. 

8 atCRS 

CAMac bulletin NU 10, JULY 1974 
MABA 
B BECKS 

B BfCRS, 2EL, KFA, JUELICM 

OECTape 

JANUARY 1974 

PDP-11# 1«K 16 BIT "UROS UF MEMORY 
TYPE 16J3A I HORtR) 

DOS VOB UR V09# 16K 

COMPILEP 

BASIC 

IN-LINE 

CAMAC suft-ahe IS macro assembler 
single action statements 


description- - 

TMIS COMPILEM IHANSLATES TESTED tlNTtHPRt T 1 Vt ) BASIC 
PROGRAMS INTO MACRU-U SUUHCt CODE, R. N TIME IS ImPmUYED BY 
A FACTOR OF IB TO 20, EASILY ADAPTABLE 10 UlMtR EUNtHULLERS 
(MACROS), 

OUTPUT CODE LINKED -ITH FLOATING POINT PACKAGE CAN HUN ON 
STano-ALIINE MIM-cOMRuIERS, 


HEADER SERVICf REF NU 14,6036 

CL*S3 coot . ,643 

TITLE- . - - PRtCOMPlLtR FUR IML SUHSE! 

AUTHOH(S)- • R, KNtlS 

POOL, REF, • CAMAC bulletin NO 10, JUNE 1974, AND GF K 

REPORT KFK2121, GFK, 1978 (IN PRESS) 
NAME/ACRONYH • META-II/x 

obtainable from r, KNEIS, IAK ii/cvcluthun,gfk, 

0 7600 KARLSRUHE, PUSTFACM J840 
available ON/AS TAPE, C*RDS 

OPtHATIVE date- JULY 1974 

COMPUTERS- IBM/370 (TRANSL,), LDC 3)00 (EXECUTION) 

INTEHFACEtS) • IN-MnUSE TYPE 

MIN MfMOHY SPACE J6K BYTES (MAX 86K BYTfS) 

software type • PRECOMPILER (METACOMPILER SYSTEM) 

LANGUAGES- IML (USER), FORTRAN IV (SVSIEM), 

MET*. II (FUR COMPILER/-RIIING} 

INCUPP TECMMUUt IN-LINE 

HOST language - COMPASS ASSEMBLER (CDC 3100) 

FACILITIES • single actions, MULTIPLE. acTIUN(ma) 

»LUCkTHANSFER(UHL), and lam-, 
crate-, and STSTEH-STATEmENTS 


DESCRIPTION- . 

META-n/x IS A system for kRITING LUMPlLtRS, IMt iMWLt- 
MENTEO version Of (me IML RRECUMPILEk IS A CMUSS-CUMPlLtR 
VERSION, i,E, TRANSLATION IS DUNE ON AN iBH/J7U, E>tCUI lUN 
UN A CDC 3100 tUMRUTER, IME OBJECT LOUt EUR PRELUMPlUiNG IS 
THE MNEMONIC CUMRaSS ASSEMBLER (CDC), THtREFuRt AN AUDITiU- 
NAL assembler step is INVOLVED, «1Tm MLIA-11/X A PRECOM- 
PILER CAN be -Mil ten and tested in a FE- days, the IML SUB- 
SET contains THE DECLARATION- (LUCL, LUCU) ANU At T lUN-ST A I E> 
MENiS (SA, SJU, SJNU, MA, UBL, ALL LAM HANDLINV^-, SYSTEM- 
and CRaTE-CONTrUgLRR- STATENENTS), 

SET CONTAINS T"t DECLARATIUN STATEMENTS LOCL AND LUCU, IMt 

SUBSET Alsu contain action statements SULM as sa, sju, sJnu, 
MA, UBL. all LAM-manDLING statements, SySTEM SIxtEMENTS, AND 
CRATE controller SIATEMEnTS, 


HtADEH SERVICE RtF NO 14,6036 

CLASS CODE - ,64x(B4SlC) 

TITLE- - • - A PDP-11 BASIC EXTENSION FUR C*«AC 

P)iUCRAMM|NG 

AUThORCS)- - 1 HALS, E OE AGOSIINU, CNEN, ROME 

PURL, REF, • CAMAC BULLETIN NO 7, JULY IS7J 

OPERATIVE date- 1973 

computer • POP-11 

INTERFACt(S) - executive SUITE (GtC ELLlUTT) 
SOFTWARE TYPE * INTERPRETER 

INCORP tecmmuue subroutines in assembly code 

environment FUR - CAMac SOFTWARE IS BASIC 

language • BASIC (EXTENDED) 


reader service ref no 14,5037 

CLASS CODE « ,644(BASIC) 

TITLE- - - - A CAmAC EXTEnOEO BASIC LANGUAGE 

AUIHOHCS)- • J M SLRVENT (SChLUMBERGt R ) 

PUHL, REF, • PRUC CAMAC SYMPIIS, LUXmbG, UtC 19/3 

name /ACRUNYM, • . CASIC . 

obtainable from SCMLOUHERGER (SEE INDEX DF HFRS) 

OPEHAT I VE date- 1973 

COMPUTER • PDP-11, f6K WORDS mEmORy 

INTERFACt(S) • ICPll UR JCC 1 I (SCMLUMBLRGtR) 

MlN system CONFIG T)» 

SOFTWARE type • IMFRPRLTIVE LANGUAGE, EXTENDED 

with MACRH-INSTRUCtlUN GENtwATOR 
language - BASIC (EXTENDED) 

incCiRp Tecmmuue in-line camac STAieMtNrs 

CAMAC FACiLiriES Symbolic ntvict names, iniehRupi 

MANwuINIi, RE-ENTRANI, 


DtSCHlPTIUN. . 

TmE subroutines wmICm extend TmE basic IMERPHtltR TU LAMAC 
ARE called by an EXIERNal FUNCTIuN SIAIEmEmT, wmEKL ADDRESS* 
function, tic, are transmuted AS ARGUMENTS, TME SIAIEMtNl 
FiAS THE following GENERAL FUHMw • 

LET U ■ tXF (Al,A2, ,A10) 

the first AWGUMtNT SELECTS THE APPwUPHlAlE SUBRUUTINt, 
DATalESS, read, and -RITE UPEHaTIUNS SITm DlRtC T /INOlRtC T 
addressing arc PUSSIdLE, ALSU SINGLE UR BLUCK TRANSFERS IN 
address scan, repeat UR STOP MODES CAN at PERFURMEU, 
the EXTENSION FEAIURES LAM HANDLING, 


OESCRIPITUN- - 

standard BASIC IS extended wITm a SET uF CAMAC RELATED 
statements, txtCUIIUN TIME FUR A io6 LINE PROGRAM IS ABOUT 
10 SECONDS, DLCLARAtlYt STATEMENTS ALLOW SYWBULIC RtfERtNcE 
UF A module, address Parameters can be lunsiants 
UR variables, even expressions, thus providing great 

FLtXlBlLITT, SEvEwAL CUNTHOU FUNCTIONS ARE IN MACRU-SIATE. 
FiEnT form, Such as • 1ST L AM MODULE (SA"t AS MUDULEtB)), 

SOME SYNTAX LMANGES FACILUATtS IMPLEMENTATION OF T ME SEman. 
Tics OF IMU (SEE ,60I(1MU), TYPICAL STATEMENTS ARE - • 
ASSIGN aUdRESS - • STAriLN(MOOuLt) » (B,L,n,a) 
executing STATEMENI . . 

SINGLE TRANSFER - • SA (F .muDuLE , * ) 
multiple transfer • • "A{t . module, A) 

CUnIRDL FunCTIUN - Exit hODULE(F) 

lam REG uPtwATlIJN- ClR lam MgOuLt tiMUDULttlUJ) 

LAM/INTEHRuRI • • • UN LAm(muDULE) OU 100 
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HEADER SERVICE 
CL*SS CUQE • 
riTLE- - • . 

*'JTHUR(S)» • 

PUBL. RtF. ■ 

M*>'t'/*CRONVM > 
UPEHFIIVL l)*TE« 
COPHUTEH • . 

INTERFACECS) » 
SQFTPARE type • 
INCUHP rtCHMRUt 

ENVIRUNRtNI FOR * 


reader service 

CLASS CUDE • 
TITLE. ... 

AUTRQR(S). . 
VERSION. . . 
maintenance SY. 
obtainable from 
available un/as 

OPERATIVE date- 

computer • 

INTifiFACE(S) . 

MlN SYSTEM cone 10 
SOFTWARE type - 
language - 

INCOKP TECMNIUUE 


READER service 
CLASS CODE . 

title- . . - 

AUTMOH(S)- • 

NAME /acronym . 

maintenance by. 
obtainable from 
available UN/AS 
OPERATIVE date- 

computer • 

INTERFACE(S) - 
MIN SV3TEM CONFIG 

software type . 

LANGUAGE • 

INCORP TECMNIUUE 
CAMAC FACILITIES 


HEADER SERVICE 
CLASS CODE . 
TITLE- - • • 
AUThOR(S). - 

maintenance by 

obtainable FRUM- 

flPEHATIVE DATE - 

available un/as. 
COMPUTER ■ - 
INTERFaCEIS) - 
SOFTWARE type- 
other remarks 


READER SERVICE 
CLASS CODE . 
TITLE- - • - 
AUTmOR(S)- - 
PUBL, REF, - . 
NAME/ACRONYM' * 
OPERATIVE date. 
COMPUTER • 
software TTPE * 


REF NO H.bOJB 
,84A(F0C4L) 

FOCAL overlay Fur CAMAC DATA 

AND command MANULINB 

F may, M mALLInU, K PETRttZtW 

CAMAC bulletin no 1, JUNE 1971 

FOCAOAT 

1970 

POP-B, OR 8K 12 bit WORD MEMuHY 
IN-HOUSE CC E INTERFALF 
interpreter (EAIEnUEO) 

CAMAC EXTENSION Of UVFRLAY, 
in-line coding Of CAMAC COMMANDS 
CAMAC software is FUCAL 


DESCRIPTION- - 

TMl INtERPREIfw. IS PwIMAwlLY INTENDEU FUK EASILY PhugRammE,, 
ON-LINE CAmal systems IN NUN-1 IMt -LR IT iCAL CUNIWUL «NU DATA 
handling ARRLlCAriUNS ANu EUM USI WUDIlNLSi 
TmLRE awe 9 LAMAC SUIEMEM TYPES LUVEWlNO GENERAL LUN I MULS 
(2, C, 1) AND CAMAL commands -Iti/wllMUUI UAIA fWANSfER, 

TmE general form UE a camal sTAftMtM IS — 

♦A Cf .C,N,A,F ,EB,»w l,L-,UJ 

-here several RAwahEIERS may ml OMITIEU, 


REF NU 14.S0J9 
,54A(BASIC) 

b-user Basic under uus -itm 
INTERPRETER EXTENDED FUR CAmAc 
PFEIFFER, SPICKMAN, CAHLEBACH 
001 

D P PFEIFFER 

D p PFEIFFER, ZAM, kFA, JUELICM 

DECTaPE 

JANUARY 1974 

PDR-tl, 16R OF 16 BIT wORD MEMORY 
TYPE 153J4 (BORER) 

DOS VOB OR V09, 16K 

DOS SYSTEM interface 10 CAMAC 

basic 

extension of interpreter 


description- • 

THE B-USER BASIC CAN flE RUN UNDER DUS, A HELM FILE CUNlAlNS 
all modifications of TmE I TO B USER BASIC, NO IMEKKuRI 
mAnolING, CUMmuMLAIIUN BtT-ttN ImE B uSEwS IS POSSIBLE By 
ONE COMMUNICATIUN WORD PER USER, EXPANDED EmROR MESSAGE 
MANDLInG/HLE mANDLING extended, IlFit COMMAND AUDLD, 


REF nO 14,9040 
,944 

UHACL (TM), an interpretive REAL- 
TIME MONITOR WITH CAMAC SUPRUHT 
L BYARS, R KFYSER (URTLC INC) 

ORACL (Tm) 

ORTEC 

ORTtC (SEE INDEX UF MANUFACTURERS) 
PAPER tape And DISK 
APRIL 1974' 

PDP-11, MIN 9K IL BIT mEmURT 
TYPE DCOll (E6»G) 

YTY I DCOll 

INTHEPRETER, SYSTEM MUNlTUR 

pop-ii assembler 

embedded CAMAC FEATURES 
single UR multiple INSTRULTIUNS, 
demand handling is included, 


description- . 

UHACL IMERPREIS AWIIFimETIC STATFMEnIS, PHuGwAm LUNTMOL 
statements, LOMMtNTS, 1/U STATEMENTS, AND hAwU-Awt CUNIkUL 
STATEMENTS and EXELUttS The DESIRED FUNCIIUN, 


ORACL (Tm; is a TRADE MARK REGIS I EREU BY UMT EL , INL, 


ref no 14,9041 UESCklPTlUN- - 

,944 

general purpose i/u interface Software 

F WORM, SEN ELECTRUNIUUE 
SEN 

SEN (SEE INO^X UF MANUFACTURERS) 

MAY l«7i 
DISK 

NOVA SERIES (DATA GENERAL) 

ANY (IRRESPECTIVE OF MAKE) 

Interpreter 

FULLY RUnS/SOS CUmPaTIULE 


. 55 Support Software li 


REF NO 14,5042 
,99J(FUCaL/PAL) 

A FOCAL interrupt mandlEP fur CAHaC 

F MAY, w mARSCMIK, m MALLING 
tVMAC bulletin no 6, MARCH 1973 
(fUCALINT 

PTB.B . 

SnILRRUPT handler (SYSTEM PWligRAm) 


DESLkIPIlUN- . , 

fUCAlInT is a general PUWPuSL system PMUGHAM, AUAPIABLL fuh 
SPECIAL USE, UP lu J CRaTES wlT" 24 jNrEWWuPTS LALH CAN BE 
SERVICED, ONE PROGRAM LINE IN FULAL IS wEStwvtD FUR EACH 

interrupt, short ROUTINES can be lYPtu iNiu These lines 
servicing TmE ASSULlATtU INTERRUPTS, ALIERNAUvELY 4 FOCAL 
SUBHOUTTnE LAN bE USED, CuwhEnT LINE IN Int baLkGhOunu 
PRUGR 4 M WILL BE FlNIShtU BtFukt JUMPING lu InURwuPT wuuIInE 
AND HFTUHnS II) Ntxl LlNi In IKE bALKgHuUND p-UGWam afTEK 
SERVICING, 
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■t«0f« 

CL*II coot • 
TttLt* ■ • • 

OTNt* aixAHIIt 


■ItOta IlMviCf 
Ctut coot • 
titll. . • . 
*UTHO*(t)« . 

U»/«t 

oaiatTivi o*Tt« 

CUMuTl* • 
lott^'tctd) • 
iu*r>*»i tT»i . 


■t(Dt* ItHvICf 

citii cool • 

T|tll. ... 
<urNua(0). . 
UOT*|k«|Li »*U" 
uatatMvi u*ri. 
cu**»ott« . 
HTiaMCtO) • 

lUfT.tai Ttot . 


MA0t« idvice 
CkAtt coot . 
MTLf. ... 
otTAtNitkt rauM 
oaiaATivi UATt. 

iaTia»AC((*> • 
lOaayTfa . 
lOAT.iat ITPC . 


aiAOia ttavicf 
CkAlf coot . 
tITlI. ... 
OlftlNAIkt »HUn 
Un*AT|«f 0*Tt. 
C 0 «»UT|a . 

lartaAtceia) . 
furr.tac T?at • 
LANCuASt • 


aiAOta tlHaict 
CLAll coot . 
T|TU. ... 

oatAjSAOkt aauM* 

COaayTta . . 
IMTlUAACtd) • 
lUAT.Aaf rvat. 

■la I»ST£" coaait 


.57 Test Routines 


at* au la.taaj Ot»CK|*MUa. . 

A |£f Of iH.kt UlAwayklll •'m>b«A»a A>k »ya*>bitw I»l 

tt*T aaucaA.i >ua |tsit»l. a«Ask» ■ac.ii ■ica>4*'aubMA»«tu a*AaC* Itkil u> ■txu*'. »Ut 

OaNt* t MUOyktS ■twlirtat. lallayCUya kiT, y.A iMAakAtak. lalta.yt'lk tTk, 

• I (Ilk lMOt> If "fail A tuafktit Kllta ItIT IS kuafklty »H" k|v2, 

foa laAkCH oa|y(a ■eo.||> S>kTi» UK a ca.aC ikK auuMak Ik kuafklto »ua (a"a( "ubyLk UkTiaw 

ayOwLk atei. Aao UAIA HOOyktl A«0" ThI IkktMfk. ay AklkKay* kAakWAkk Aau.LtOkt atyul.kM, 


atf au lA.SCAA 

CAMAC rtST aaukHA" 

Oa, • «faTfa|, ]«■, AfA, jykktC" 

fAfta tAff, ASCII coot 

I9f| 

*oa.||, |k« Ok Ik ait >uaus Mtaua* 

Tvai SIOS (auakM) 

ItST ai)yTjakS( STAau.Akuak )'auk.A«S 


ytSCaiatloa. . 

SiAap Akuak •'auaaA.s TkSf auai kua(T|yas u» |xk ayaka )*at 
fSOS tallMAAll. TMk k.Alk (uat.Uk.kka A.y t.u |a..uuSk 
aOUUktS (Cll t COS), 

taayii afSS*akS A.k uytayT |t f.kak A.k aA.w.AMk kAlkU.kS. 


atf ao lA.SOfS 
,SfS 

JtllA ttst CAMAC 
k A AkAlSaka 

alatTIC iTStiaS (SCk laOtA uf ■».!) 

*oa.|i, 4« Of cuat "i"oa» Nkuyl.lu 
tvat JsiiA (aiattic) 

t(St Huuttar 


OtSkaifTlOa. . 

A KtaO AkUak MMykaA. fo. kikaciklak a Ca.a( S'klta fay. a 
T tktTfft, It kyafuats ya tu S C.Atkk >11. auUkk fall* 
yalauS •) (aAtt kUat.OkktaS. a Ayadlua mat ak kiktutky 
uact oa akfkt|tt»kkt, 


a) yatkuS IS A tMAUk .A. A UA UlbltAk lauifakat (u.a. 


atf ao lA.SOAk 
.KJ 

ttst tA«AC 

«|att|C StStl.S (Stk laOlA Of aAMS) 
IttS 

ttat ASSSII (alattlk) 
foa.ii. AA Uf cuat akyyiako 
ttst aouTlat 


OlkCNiftiua. . 

A stAao AkUak aMuk.A. Ay. kAtaklklay A kfaAk ktstta A.y" a 
ttkttffti It kuafuats yat a.Aata yai»ka .tt. yf ty t 
CaAttS, A tyAiitlua .Af kt lAttyltv yaci y. aka( 1 1 1 1 Akkt , 


•tf ao |A,»OA/ 

.ktj 

fOf.ii latfUfACk Itkt fauwaAM 
CtC.lkklOTt (Stt lavti Uf MAaS) 
IStf 

fijf.ll 

*Df.|| tifCutlfl kyKt /btk.tkklutt 
ttst aouTiat 
fAk.ii ASSfaakta 


yksraiftiua. . 

tall !S A kttay.Akuak a.yy.Aa ySky |a k"k(A|ak tnk kftkU'i<t 
*y|tt> A ayyykAM aya.|| . (.A.AC |ai(.fACt, UlAyayktlC 
■tkSACkS A.k IkSyky. 


atf au lA.kOfS 

ttst paucaA.s fua a.Aaca uaivta a.u 
I tstta .|tM ayOykt aiOS Aao tvat A 
II aa StsttaS (Stt laotA uf afas) 
aaiai cuaaytta 
IZkO (SI aA STSt(aS) 

OlAk.UStlC aauOaAaS 

laAaca yaivt* IlkO. kl02 Camac ttst 

■OOVLt/OAt A.AV DlkfkAf 


ytscaiftlua. . 

A Skt uf OlAbAiUSIIk aHuk.AaS A.t kua.kily .11. fnk ayOkk 
1260 aal.t kuaaylf* s.Aai. yaltka, 

A Cuafkttt ktstta Itkt IS kyaakity. ayl .kayiakk "UUkk 616 a 
ttst .uOukt. 
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SPACELAB SOFTWARE DESCRIPTION 


(Reproduced from "Spacelab Payload Accommodations Handbook 
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Tha Spacalab Computar Softwara comprisas tha softwara usad for Spacalab during software davatop- 
marts, intagration,tasttng, and operation. This Includes subsystem tasting. Integration, chacKout, on- 
board data handling for subsystems, on-board data handling support for experiments, and checkout for 
the COMS portion of ths< experiment Interfaces. Also included is certain support softwara used In the 
generation and validation of software and for the off-line reduction and analysis of checkout data. 




Software especially dedicated to experiments Is not included in tha Spacalab computer software. 

TTie Spacelab computer software is made up of sets, each of which is the assembly of software, used 
for a particular phase of the Spacelab program, with a specific computer system (experiment computer, 
S/S computer, SGSE, or Software Development Facility). 

A set is made up Of a number of packages. 

A package consists of a group of software modules which are used together to perform some clearly de- 
finable functions. 

Fig 4.5— 1 thru -3 give an overview about SL. computer software and the Interrelationship between packages. 

The Spacelab computer software Is designed in a modular way In order to allow for good testability and 
meMimum use of common functional units. Thus commonality can be achieved between the experiment 
and subsystem computers concerning the operating system and general facilities, such ats operator inter- 
face, monitoring, fault Isolation, subroutine library, etc. ‘ 

Packages relevant for the experimenter aret 
e CDMS Computer Operating System Packages 

This package consists of the subsystem computer operating system (SCOS) and the experiment computer 
operating system (EGOS). For details see 4.5.1.1 - 

e Support Software Packages. 

The experiment application software packages running In the experiment computer under the ECOS will 
be supplied by the experimenter and/or the payload Integrator. 
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4.5.1 Spacelab Software Environment 

The experimenter — when linking up bis experinr>ent software with the Spacelab computer software has 
to deal with the CDMS computer operating system package running in the experiment computer (ECOS^ 
an<i with those modules of the flight 2 ipptication software packages (FLAP) which are also applicable to the 
experiments and which can be regarded as facilities available for applications. Furthermore, means are 
provided to support the experimenter in compiling, testing and integrating his software. 

4. 5 . 1 . 1 CDMS Computer Operating System 


The CDMS computar operating system is at present the same for the subsystem (SCOS) and the experi- 
ment (ECOS) computers. However, because of the requirement that the experiment computer operating 
system accommodates a variety of experiment applications the ECOS may eventually grow to include 
greater capability in the areas of control and data processing. 

i" 

The ECOS allows for asynchronous as well as synchronous tasks to be performed. The executive per- 
forms initialization, scheduling and termination of tasks. It assures time scheduling, loading of tasks in- 
cluding overlay and memory allocation to them, management of the various data tables in the data base for 
program control and housekeeping* It controls the allocation of the computer peripherals, such as 
memory, keyboards, data display unit, telemetry channels, and data bus. The executive allows 
for initialization of the computer system and for convenient recovery after system failure. The executive 
includes a computer self check which is executed periodically, providing a message in case of failure. 

The input/output functions provide all services necessary to operate the remote acquisition units (RAUF'S 
para. 4.4.2. 1 ). They format and transmit data to the CRTs for presentation to the crew and experiment- 
ers, receive and process external event messages based upon usage of the keyboard and inputs from ex- 
perimenters. They permit communication with the Orbiter for reception of commands, state vector and 
timing data. They perform the transmission of data to the Orbiter for Inclusion in downlink telemetry. 
They check the status of the peripherals (parity checking, data ready bits, data available bits as appli- 
cable). 

The functions summarized as general facilities are functions common to all or most of the application 
programs and include services such as converting of raw data into engineering units, library of 
mathematical fonctions , etc , 

The ECOS is able to monitor experiments, and to perform limit checking aund calibration of data for dis- 
play-. , 

The ECOS is considered to be core resident with the exception of display formatting routines which will 
be stored on the maiss memory (ref * para. 4.4). 
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Th« size of ttm ECOS Is TBO. 

Average operating system ovemead is estimated to be S % of CPU time. Reaction time of external events 
is estimated to be 100 yusec maximum. 

The S/^ - interface between the ECOS and experiment application packages is managed by super- 
visor calls and data tables. 

The S/W - H/WinterfSce between the ECOS and the peripheral hardware is handled via dKvera in the 
ECOS which perform activation, status check data transfer and termination on the peripheral. 

A keyboard language for communication between operator and exparin^nt computer will be provided , thus 
the ECOS provides the interface between the operator and the computer system. 

The functions involved are calling for data display and computer status display, initiating and termination 
of experiment moi^lea at predefined points, intenpretation of keyboard commands and changes to expert- 
ment modules. 

The ECOS will be capable of displaying on CRT structures representing all the groups of data which may 
be selected for display. In addition, the capability will be provided to generate and display on-line a spe- 
cific list of data on operator request. 

4.5.1 .2 Facilities Available fbr Application 

The experiment 2 ipplication software for the experiment computer is the software executed by the ECOS 
and consists only of the monitor and fault isolation mocKjle for the experiment portion of the CDMS. All 
experiment related software packages to be loaded in the experiment computer are produced by the ex- 
perimenters. 

Only some of the modules of the Spacelab flight application software (FLAP) can also be used by the ex- 
perimenter. 

Within the FLAP there are modules available for management of electrical power and energy which make 
the respective information available for the experimenter on CRT by request via a keyboard entry to the 
subsystem computer. In addition, it will be possible to update-in predefined areas of memory-values and 
limits per telecommau->d and/or keyboard. 
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4. 5. 1.3 Software Integration 

For integration of his experiment application software, the experimenter will be supplied with the follow- 
ing software (para. 4.^2): 

e CPMS - simulator 

This software will simulate on a host computer the CDMS environment 

e Interpretive computer simulator (ICS) 

This software simulates the Mitre 125 S/MS on a host computer 

e Experiment computer operating system (ECOS) 

The CDMS environment simulator euid the ICS can be integrated in order to simulate the complete CDMS 
on the host computer. 

4.5.2 Software Development Aids 

This software is part of the support software packages to be used for the effective development and main- 
tenance of all Spacelab software, i.a. hot only for the experiment software but also for operating systems, 
ground checkout packages and the flight application packages. 

This means the experimenter, in developing his experiment software, shall utilize the facilities provided 
as far as possible. Experiment software shall be written in one of the languages explained in para. 

4. 5. 2. 2 which are available with the host software system (see pare. 4.5.2. 1). For debugging the simula- 
tor software shall be employed. 

4.5.2. 1 Host Software System 

The host software system comprises all that support software necessary for the development of all experi- 
ment software and executed on a host computer (IBM/370), The following items will be available. 

e HAL/S - 370 Compiler System 

This compiler system can be used to test programs written in HAIVS on au-i IBM 370. 

The compiler will compile HAL/S statements into code executable on an IBM 370 
computer. The ^stem also Includes an execution monitor under which the compiled 
code can be executed. 

e HAL/S - CII Compiler 

This compiler will compile HAl_/S statements into code executable on a Mitra 1 25 S/MS 
computer. The compiler itself will run on an IBM 370. 
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GOAL Compiler 

The GOAL compiler will compile GOAL checkout statements into interpretative code. 

The interpretative code can be executed by an interpreter running on a Mitra 125S/MS 
computer. The compiler itself will run on an IBM 370. 

Interpretative Computer Slnmjlator (ICS) 

The ICS will simulate the Mitre 125 S/MS. This simulator will execute on an IBM 370. 
Mitre 125 S/MS Macro Assembler (MAS) 

Two versions of the assembler will be available. One will execute on IBM 370 and one 
will execute on the Mitra 125 itself. Code generated by either one can be processed by 
the EOL (see below). 

Mitre 125 S/MS Linkage Editor (EDL) 

Two versions of the EOL will be available. One will execute on IBM 370 and one will 
execute on the Mitra 1 25 itself. Code generated by either one can be processed by the 
preloader. 

I/O Bex and Peripheral Simulator (lOBPS) 

This simulator will simulate the reactions of all COMS hardware (except the computer) 
with respect to computer input/output and outside events. The lOBPS can work together 
with the ICS. It will execute on an IBM 370. 

Programming Languages 
HAL/S 

Experiment software may be writt^ in the programming language HALyS. This Is a real 
time programming language which allows the scheduling and synchronization of programs. 
The language also allows the manipulation of vectors and matrics and data structures in a 
simple manner. 

A wide range of mathematical ftjnctions is available with HAL/S. 

Experiment software may be written in Cll MITRA 125 S/MS asiembler language. 


Checkout software for experiments may be written in the checkout language GOAL. This 
language is oriented tovsirds the convenient specification of checkout procedures by scien- 
tists and engineers. 
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4.5.3 Software Development Guidelines 

Software development guidelines and standards* eks well as procedures for the technical management* 
will be provided within the Software Standards Manual (Doc. No. MA-ER-0001). 

There are two main topics: One covers the part of technical management such as verification (reviews 
and acceptance) and configuration control. The other specifies the necessary guidelines and standards 
to be followed during software development (design* implementation * test and documentation) to satis^ 
the requirements of software control. 

As far as the user‘'s Interaction with NASA/ESA is concerned and to en 2 Usle NASA/ESA to control and 
integrate the experiment software, the user will also have to follow soma of the corresponding procedures 
and guidelines within the Software Standards Manual , 

The relevant topics will be referenced In a manual of guidelines for exf>eriment software. Additional 
guidelines* e.g. safety requirements, constraints oh size and frequency and overall memory require- 
ments, will be included. 
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